In cryptography or science in general, you often need perfect random numbers. Well, up to today, that was my need as well. However, today I was trying to generate numbers that are not too random, but have a certain bias. I think it’s kind of ironic. Googling for a solution is almost impossible. Every link shows a perfect random number generator 😉

I don’t care what the bias is in the numbers that are generated. Actually, the bias can be pretty high. Anyone have a method to do this in Perl?

Can you do something like int(rand($upperLimit*1000)) % 1000 ??? Basically changing the interval from where the random number is taken and then shrinking it again?

I came accross this really nice library of R graphs and scripts. One that I really liked is a scatter plot with histograms for each of the axes. The code to generate such a graph is the following:

Dataset < - read.table("/home/ram/foo2_200.csv", header=FALSE, sep=",") x <- as.numeric(Dataset$V2) y <- as.numeric(Dataset$V3) nf <- layout(matrix(c(2,0,1,3),2,2,byrow=TRUE), c(3,1), c(1,3), TRUE) par(mar=c(3,3,1,1)) plot(x,y,xlab="",ylab="") par(mar=c(0,3,1,1)) xhist <- hist(x, breaks=seq(min(x),max(x),(max(x)-min(x))/24), plot=FALSE) barplot(xhist$count,axes=FALSE,space=0,col=heat.colors(24)) par(mar=c(3,0,1,1)) yhist <- hist(y, breaks=seq(min(y),max(y),(max(y)-min(y))/24), plot=FALSE) barplot(yhist$count,axes=FALSE,space=0,horiz=TRUE,col=heat.colors(24))

And the result looks like this:

I am still playing with R to generate graphs. I have to say, after some initial frustrations, I think I start to get it. Here are some steps to generate parallel coordinate graphs in R:

Dataset < - read.table("/home/ram/foo2_200.csv", header=FALSE, sep=",") require(lattice) parallel(~Dataset,data=Dataset)

That's the very basics to generate a parallel coordinate plot. An interesting addition to this is to use a different command to generate the parallel coordinate plots:

parallel(~Dataset|Dataset$V4,data=Dataset)

This will generate n different parallel coordinates, one for each of the values in Dataset$V4 [where Dataset$V4 is the fourth column of our data].

Following is my last attempt. I wanted to change the axis labels. The y-axis I was sucessful in changing. For the x-axes, I was not able to change the labeling. I guess this is precisely the problem with R. Simple things are fairly simple to do, but if you want to change specific details, it gets quite messy quite quickly.

parallel(~Dataset,data=Dataset,varnames=c("Source","Port","Destination","Action"))

I just returned from a hearty breakfast on the 22nd floor of my hotel, overlooking Frankfurt. Great hotel, great views! I was flipping through the pages of the ISSA journal. I haven’t really posted any article reviews in a long time. I got too frustrated, I guess. There is this article, I just can’t resist but making two quick comments. The article was posted in the January 2007 issue and is about managing passwords. The first thing that hit me is that this author actually gives us two email addresses in the “About the Author” box. Why would I need two addresses? Isn’t one enough? Anyways. Sorry. What I was really confused about is that the author talks, in the very first paragraph, about:

“I cannot wait for the day when my PC offers two-factor authentication. -snip- I can’t begin to quantify the convenience that will come from having to convince just my PC that I am who I say I am, and then letting it handle the task of convincing the myriad financial institutions, -snip- that I am who I say I am.”

Wow. Maybe the author should read up on two-factor authentication and the topic of single sign on. They are not the same. And believe me, two-factor authentication is not going to ease your life! It’s one more form of authentication. How can that be easier than two? But again. Single Sign On is not two-factor authentication. It’s a fairly big step between two-factor authentication and single sign on! And I am  not sure whether I really want that. Topic attack surface!

I love travelling, not because I have to cram myself into a small seat for 9 hours, but because I usually get a lot of reading done. I was reading this paper about Preparing for Security Event Management by the 360is group. I like the article, there are a lot of good points about what to look out for in a SIM/SEM/ESM deployment. However, some fundamental concepts I disagree with:
The first step in deploying a SEM (Security Event Management Solution) should be to get an inventory, to do an assessment. At least according to the paper. Well, I disagree. The very first step has to be to define the use-cases you are after. What’s the objective. What are you hoping to get out of your ESM (Enterprise Security Manager [I use these terms interchangeably here]? Answer this question and it will drive the entire deployment! Out of the use-cases you will learn what data sources you need. Then you will see how much staff you need, procedures will result from that, etc.

The second step, after the use-case development, should be the assessment of your environment. What do you have? Get an inventory of logging devices (make sure you actually also capture the non-logging security devices!) and all your assets. I know, you are going to tell me right away that there is no way you will get a list of all assets, but get at least one of your critical ones!

Another point that I disagree with is the step about “Simplify”. It talks about cleaning up the security landscape. Throwing out old security devices, getting logging configured correctly, etc. Well, while I agree that the logging of all the devices needs to be visited and configured correctly, the task of re-architecting the security environment is not part of a ESM deployment. You will miserably fail if you do that. The ESM project will be big enough as it is, don’t lump this housr-keeping step into it as well. This is really a separate project that falls under: “Do your IT security right”.

I am reading a lot of papers again and I keep finding research which just doesn’t get it. Or at least they are not capable of cleanly communicating the research. If you are doing research on visualization, do that. Don’t get into topics you don’t know anything about. Don’t get into common event formats for example! Make assumptions. Let experts in that field make a call. Let them figure some things out. You can say what you did to overcome your challenge, but don’t – please don’t – mention those things as a contribution of your work. It actually does two things to your research: First it distracts people from what you really did, and second, it misleads others that are not experts in that field to believe that you have a viable solution. So, visualization is visualization and not log normalization!