On September 18, the (US) "President's Critical Infrastructure Protection Board" released a draft for comment of "The National Strategy to Secure Cyberspace." Security vendors jumped on the band wagon, bragging about their involvement in the process (as if involvement from CEOs and Senior VPs will solve security problems). The government has scheduled "Town Hall" meetings in which the slightly more educated will hear comments from the uneducated about this document. This month, I'll make some comments, observations, and recommendations.
It is not clear (to me) where they got the ideas for the cyberspace. Maybe there are references, and I just missed them. Nevertheless, they are all commonly prescribed good practices. Unfortunately, the reader will have to sift through a lot of boilerplate and "government-speak," an unclear and laborious writing style that attempts to say everything it possibly can, as if the writer were paid by the word. (Government writers believe this is necessary, and will not be persuaded otherwise, thinking that there are special requirements for them.)
Also, it is aimed at the "lowest common denominator" -- the person who knows nothing about the need for Internet security -- and so goes into great detail to make the case for the need for computer and network security. I suspect this is overkill, but for the person who just arrived from another star system where people are polite and mind their own businesses, it won't hurt. I recommend anyone who knows anything about security to just skip to page 61, the "summary of recommendations." The writers used some old data (the insider threat at 70% is from a 2 year old study, I believe), but what they say is mostly correct.
The document does not recommend government regulation, invoking federalism. Government will encourage through example and purchasing. Also, it is primarily an awareness program. This is reminiscent of the "Smokey Bear" campaign of the USDA Forest Service. Every "boomer generation" kid knows "Only YOU can prevent forest fires," and knows that dealing with a campfire, you "drown it, stir, and drown again." I know it, even though I never, ever camped when a child. Did it help? Well, *I've* never started a forest fire, so maybe.
Every home user should read the guidelines for the individual and small office. It is all "good stuff." True, it has all been said before. Maybe if the government says it people will do it, but probably not.
The guidelines for the large enterprise, again, are things companies should know, should have heard, and should be doing already. Again, maybe they will if the government suggests it. I don't think so. An example: it took seat belt laws to get them in all cars. Drivers were not asking for them (and still some people don't use them). For companies, it all comes down to profit and loss. In many large enterprises -- and in the Federal Government -- security is always second place to usability.
The guidelines for the Federal Government itself are the most bothersome. For example, "establish an Office of Information Security Support Services within the Federal government..." In typical government fashion, it solves a problem by adding more bureaucracy. A concern I have is that the guidelines look at the Government (also Large Enterprise) as one single entity that can be understood and controlled, if not tamed. Until we start thinking about compartmentalizing organizations -- protecting little offices from *everyone else* -- the problem will remain unmanageable. No government office or agency (e.g., the OISSS -- blech), no matter how big, can make sure the entire US Federal Government cyberspace is secure or that each agency and department in the government is following regulations.
Here's what *I* think is needed, and not addressed, unless I missed it (and I might have in all this text).
First, consider regulation of U.S. Internet Service Providers (ISPs), with the goal of "raising the bar" of security for their networks and the customers. There are many things that most ISPs can do, from supporting strong user authentication for access to services, to encouraging the use of VPNs (rather then discouraging, by rejecting IPSec packets).
Next, ISPs will require a certain level of security from enterprise and broadband customers, through adherence to and adoption of recognized good security. Perhaps dial-up users are below the radar on this, but every enterprise network and every "always on" high-speed connection will be required to have a firewall in place and virus screening, or they cannot be customers. ISPs now police adherence to acceptable use policies (and use these to kick off "spammers"). This would just be an extension to the AUP.
While I do not generally like solving problems with regulation, this is similar to national regulations for auto safety and inspections. Highways are safer when trucks and cars have minimum safety requirements. Is there a cost? Sure. It may be the only way. I understand arguments against regulation. But to connect to the Internet, driving proficiency and an approved safe vehicle should be required and would help protect us all.
I have a new course -- developed with TruSecure Corporation -- called "Investigative Response." Please check it out at http://www.avolio.com/CourseDescr.html.
Next week (October 14 -- 16) I'll be at "Next Generation Networks 2002 (NTN2002)" in Boston ( http://www.bcr.com/ngn/default.asp). On Monday, I will teach "Emerging Security Technologies for Network Warfare." Wednesday, I'll moderate a panel -- "The Sad and Increasingly Deplorable State of Internet Security."
October 29 and 30 I teach "Internet Security Tools and Techniques" ( http://www.avolio.com/courses/tools+techniques.html) at NIST in Gaithersburg, MD.
November 11-- 15 I will be at the CSI 29th Annual Computer Security Conference and Exhibition in Chicago. I'll speak on wireless security, on applying synergistic controls, and teach the same Tools and Techniques class.
Check out my speaking and teaching calendar at http://www.avolio.com/calendar.html and courses and services at http://www.avolio.com/services.html.