Gated communities - a good idea for data

Humans started by locking their homes (username and password). When this wasn't enough, some put bars on their doors and window, or used multiple locks (strong authentication and multi-factor authentication). As criminals evolved, alarm systems were developed (IDS). Now we see gated communities. We need more gated communities. Not for people--for data. I'm talking about networks where all the traffic flows are engineered and only what is expected is allowed to cross the network.

What does a gated community look like? For one, every router is configured with ACLs and a default deny posture. Only traffic that is expected will be allowed to pass. Let Windows workstations talk to domain controlers, but don't let them talk to other workstations. If a web server has to talk to a database server, let it, but don't let anything else talk to the database server. Every traffic flow should be engineered down to the host/port pair level. General web browsing can occur through a proxy. Which would you rather do, defend against malware on 5,000 desktops, or a single proxy server.

Sofware vendors could provide a list of the traffic flows that need to be allowed. Once this catches on I can see software and hardware vendors coming up with an API of sorts where the software install process will generate a file that an administrator with the proper credentials can import into communication equipement to allow the necessary traffic flows.

To be sure there are a lot of nuts to crack to make this work and be accepted, but I believe that this is where we are going to have to go to address the current threat environment. Will it cure all problems, not by a long shot, but I know I would sleep better if I knew that my desktops could only communicate with three servers, and only on specific ports.

I'd like to hear what you think. I am especially interested in hearing why you think this wouldn't work; those are the questions and comments that will drive us to find out how this can work.

A vigilantes' approach to combat phishing

On occasion I have responded to phishing emails with a visit to their web site using a very well patched and secure browser. In the first name field I enter "I. M." For a last name I use "Notanidiot." The rest of the fields are filled with expletives. While this is more to make me feel like I am doing something because the phishers probably speak a different language, with different expletives, it does beg the question, what if everyone did this?

What if everyone responded to phishing email with bogus information? Perhaps some infosec grad student could create a mail proxy that sees these phising messages and then sends a reply with a random bank name and random account information. What if the phisher recieved 10 million responses, instead of one hundred? Would the difficulty in trying find the one hundred valid accounts out of millions render this type of attack useless? Is this a way we can collectively protect the less informed Internet citizens?

What do you think?

Literacy, Numeracy, and Technolacy?

Schools need to teach technolacy. Technolocy is to technology what literacy is to words, and numeracy is to numbers. If you go up to a 6th grader and ask her how she would take 20 dollars and distribute it evenly between 5 friends, she knows she needs to use math. Similarly, if you ask a fourth grader to describe a funny experience, he will know to use words. We need to teach students to know to use technology.

I'm not sure what this will look like, but if I ask an eighth grade student to persude her classmates of an idea that she has, I'd like her to just know to use technology. Get the facts off he web, make some charts with a spreadsheet. Pull it all together with presentation software. This should be as automatic as the the math or writing examples.

It is more important the students know to look for a technical solution, then they now how to use technology. If they know to look for a technical solution, they will learn to use technology as an outgrowth. It won't necessarily work in the other direction.

Once we have taught student to look for a technical solution - technolacy - we are well on our way to teaching them to innovate.

We fund 9-1-1 all wrong.

9-1-1 is typically funded through the Universal Service Fund (USF). You know, that 1.37 charge on your phone bill. That has to change. The current method of funding 9-1-1 based on USF is not sustainable for many reasons.

• The increasing use of cell phones destroys the one-to-one relationship between a subscriber and their 9-1-1 provider that is the basis of USF funding.
• VoIP is increasing and does not pay into USF.
• As telecommunication charges decrease due to competition in the market, a percentage-based funding scheme also decreases.
• Legal challenges (Nebraska) may further impact USF.

A pay as you go model would provide adequate funding, even as 9-1-1 use increases. There are some constraints:

• We can’t charge caller directly – that would be a disincentive to use 9-1-1 in an emergency.
• The move to mobile devices means we need to bill for 9-1-1 at the point of use, not the billing address.

An insurance model will achieve this. Here is how it works:

• A 9-1-1 jurisdiction sets a per-call rate based on its budget divided by the number of calls expected. Yearly seems like a good period for this rate-setting.
• When a caller makes a 9-1-1 call, their provider is assessed the per-call charge. This should not be difficult, as we already know the provider.
  
• 9-1-1 software could be modified to track this and prepare bills.
• The provider is allowed to add a surcharge to the bills of their subscribers equal to the total they have been billed, plus an administrative percentage, divided by the number of subscribers.
• The telecommunication provider will act as an insurance organization, by spreading the cost of 9-1-1 among all its customers.
• The administrative percentage means that acting as an insurer can be a revenue source for the telco.
• This model will work for wired phone providers too.
• The jurisdiction that takes the call gets the revenue.
  

Sample calculations
9-1-1 jurisdiction

• Annual budget $1,000,000
• 9-1-1 calls per year 20,000
• Per call charge 1,000,000/20,000 = $50.00

Cellular companies are allowed to recover costs + administrative fee. The PUC or PSB sets admin fee. For this example it is set at 5%. The Cellular provider is allowed to recover 105% of 9-1-1 charges.

Cellular company – Acme Cellular

• 10,000 subscribers
• Each subscriber makes 1,000 calls per year on average.
• Acme Cellular handles 10,000,000 calls per year.
• 1 in 5000 calls is a 9-1-1 call = 2,000 9-1-1 calls.
• A subscriber of Acme Cellular calls 9-1-1.
  
• Acme Cellular is billed $50.00 by the 9-1-1 jurisdiction.
• This happens 2,000 in a year.
• The total charge for the year to Acme Cellular is 2,000 x $50.00 = $100,000.00
• Acme Cellular gets to recover $105,000.00 for the year.
  
• This is divided among its 10,000 subscribers and billed monthly
• $105,000.00/10,000/12= $0.875.
  
• Each Acme subscriber is billed $0.875 per month for 9-1-1 service access.

I'd like to know what you think.

Rideshare organizers need to understand their product.

Ride share programs have it all wrong. They are trying to match up riders based on origin and destination. They show a lack of understanding about what car pooling is all about. When you car pool you can easily spend in the neighborhood of two hours a day in close contact with someone. Questions similar to what is asked on dating sites are more appropriate:

• How punctual are you?
• How fast do you drive?
• What radio station do you listen to in your car?
• What do you like to talk about?
• Are you flexible?

These and other questions are what is really relevant. If people knew these things about potential car-poolers then they might be more likely to ride share. Come on Match.com or E-Harmony, do a public service, use you software to match up riders. I'm sure that it will drive business to your site.

Wannop's Law

Getting Wannop's Law to be part of the standard IT lexicon has been a personal crusade of mine for over 15 years. It hasn't been getting much traction so I guess it is time to see what the blogosphere can do.

Wannop's Law states:

"For systems that must be operational over the weekend, do not work on the system after noon on Thursday"

I created Wannop's Law after an experience I had years ago. I was working for a company that produced hotel management software. One of our customers was the Woodstock Inn in Woodstock, Vermont (HIGHLY Recommended!!!). John Wannop was their comptroller I believe, and in charge of their IT systems. He always warned me not to work on their system after noon on Thursday, due to Friday afternoon being their big check-in time.

One Friday I called John with a small change I needed to make. I can't recall what it was, but it was as innocuous as changing a monitor cable. "No way could it affect the system," I told him. After some time I was able to convince John to let me make the change, which I did. Shortly thereafter a butterfly sneezed over the Indian Ocean, and Chaos theory kicked in. By 6:00 pm the system had crashed. I was on pager and got the call from John. It wasn't too serious and I was able to get the system back up rather quickly, but from that point forward I wouldn't even ask - it was Wannop's Law that nobody touches the system after noon on Thursday.

Wannop's Law should be liberally interpreted. If Friday is a holiday, then don't touch the system after noon on Wednesday. Basically, hands of important systems, unless there is an emergency of course, if you are within 28 hours of the close of business before a weekend or holiday. I have embraced Wannop's Law all these years, and it has kept me from having to do a lot of explaining, as well as kept me on the good side of many users, mangers and executives. I highly recommend adhering to it.