fred avolio's musings

I will always put a date on every report or document I produce, that is not going to get one added automatically. (E.g., blog entries and emails get a time stamp added; I don’t have to.)

I bet that literally half of the papers—white papers and other reports—I find on the Internet have no indication of when they were written. If I am looking for something on, let’s say, “Traffic Generation Systems,” (network test devices), and I find a paper “LARIAT: Lincoln Adaptable Real-time Information Assurance Testbed, I believe it would be nice to have, somewhere clearly visible, an indication of when it was written. I am not picking on the writers of this paper. As I said, probably half of the academic reports on the Internet suffer from a lack of a time stamp indicating when it was written.

Going back to my notes of things that I set aside to discuss or to comment on, I find a February 3 Computerworld article, Old security flaws still a major cause of breaches, says report. Its first line states “an over emphasis on tackling new and emerging security threats maybe causing companies to overlook older for more frequently exploited vulnerabilities, according to a recent report.” As I see it, the old but more common security threats—the old, but more common vulnerabilities—are less interesting, especially for newer security practitioners. Therefore, they get less serious attention.

The article makes some recommendations, including knowing your network assets. In other words, knowing what is is on your network, and knowing if it is behaving as you expect, will enhance your security posture.

I add the following:

• Know your network’s security posture. “Water seeks its own level.” Nowhere will it be higher than its lowest point. Or if you prefer, “a boat is only as strong as its weakest rower.” Network security is only as strong as its weakest component.
  
• Next, enforce existing security policies or remove them. Too many exceptions lower a network’s security posture and makes managing its security nearly impossible.
  
• If you are relying on reviewing log files, and associated port- and site-blocking as an important part of your network security, then you have already lost.
  

(I explain that last one in another post, The Never-ending Battle.)

I remember in the late 1950 and early 60s watching the television program “The Adventures of Superman.” In the famous opening credits, (“Look up in the sky! It’s a bird! It’s a plane! It’s Superman!”), the narrator goes on to say, “and who, disguised as Clark Kent, mild-mannered reporter for a great metropolitan newspaper, fights a never-ending battle for truth, justice, and the American way!” Superman had his never-ending battles and we have ours. One of those is relying on reviewing log files, and associated port- and site-blocking as an important part of your network security. (I bring this up in Old security flaws.)

I know of a large network installation, that is fairly secure, but does rely on port- and site-blocking. Recently, someone tried using a file-syncing service, called Dropbox. As it’s description says, “Dropbox allows you to sync your files online and across your computers automatically.” You know? One uses it instead of carrying around a thumb-drive. There is a web interface and applications on Windows, Mac OS X, and iphone/iPod touch.

Now, as one can imagine, it is against many corporation’s security policy. Why? Here is the picture. At one end is a home computer. That could be “secure enough.” At the other end is a work computer. Same story. In between is a web site, in this case, inbox.com’s web site. I am not suggesting that their server and service is insecure. I don’t know. Did you catch that? Those three words are very significant when we are discussing network security matters. You are extending your security perimeter to include a web site belonging to someone else, administered by someone else, and under the corporate (command) management of someone else. Three strikes.

Someone tried to use dropbox, and could between his home and the web site, and between his iPhone and the web site, but not between his desktop at work and dropbox.com website, neither by the web site, nor from the dropbox application program. To him, it was no big dea. He did not have a business need for it; he was just trying it out.

A few days later, he received an email from someone in the company IT department of his company, who asked what I was doing? The log files showed repeated attempts to connect to dropbox from his IP address! He asked what policy was it against, and he was pointed to a policy that talked about proprietary, sensitive, and “for official use only” information. That is a good policy, but it did not apply. There was no sensitive information involved.

He also told the person from IT, that he had successfully used SugarSync, a program that does the same exact thing on the same platforms. IT did not flag that or block that. It didn’t know about it. SHould it be blocked? What about EverNote? Similar attributes. Potentially, similar risks.

Do you see the problem? Either this sort of thing is permitted or it is not. It cannot be permitted when we do not know enough to block access to a site, but denied when we do. If we cannot affectively block it, we block it when we can and we create, publicize, and enforce a well-vetted policy. The policy plus enforcement is key. And by enforcement, I don’t just mean mitigation. I mean following through with consequences when the policy is ignored. And possible consequences will be spelled out in the policy as well. Otherwise you are involved in a never-ending battle.

Never produce or print a document of more than 3 pages without having page numbers. (The same for slides in a slide presentation.)

“Note to Self” in this blog will be just that. But, you can read them, too. They will always be short and I hope helpful to more than just me.

Texting and driving: a report on NPR’s “Morning Edition”. We need to make a law about this? Are we stupid? (Rhetorical. Rhetorical.)

It reminds me of that urban myth my brother-in-law shared with me years ago about a driver in motor home setting the cruise control, then slipping into the backseat for a beer.

I’ve used BibleReader for years, originally on the Palm handheld computer, and now on the iPod touch.
I like to follow a plan of reading through the Bible in a year. Originally, I followed a written (paper) plan, but then when I moved to an “all digital” experience, I wanted the information on my PDA. Years ago, someone wrote an add-on for BibleReader (I used on the Palm back then) that displayed a lower-case ‘d,’ and when you clicked on it, it showed a list of dates, and related verses, and little boxes to check off to keep track.

The newest version, version 4.11, not only keeps track of your readings, but also takes you there, and marks the beginning and end of the reading. Here is an example.

• Open Bible Reader.
• I like to write notes in a paper journal, so I next check to see what I am reading today, by selecting “Reading Plans” and “View Today’s Assignment.”
• I then go back to this screen and select Continue Reading.
• I read until I see “Done,” and select it.

BibleReader is available from Olive Tree Bible Software

It has been years since I published a list of Security Axioms on my web page. Note, I didn’t write “My” security axioms. They are old, probably timeless, and too-often forgotten.

Bill Murray, in his Thinking About Security blog mentions some that fit right in, in his post “Effective” Security.