Feb

20

A California District Court judge has ordered WikiLeaks to be taken off line in response to a complaint from Swiss bank Julius Baer we find from CSO magazine.  This answers why WikiLeaks disappeared off the internets earlier this week.

The order in the U.S. came after a Swiss bank, Julius Baer, earlier this month filed a complaint against the site and San Mateo, California-based Dynadot, Wikileaks’ domain-name registry, for posting several hundred of the bank’s documents.

Some of those documents allegedly reveal that Julius Baer was involved in offshore money laundering and tax evasion in the Cayman Islands for customers in several countries, including the U.S.

WikiLeaks serves an interesting and controversial role, providing a way for leakers to anonymously post information that they believe should be in the public eye. It’s difficult to argue that the site couldn’t be abused by someone posting confidential company information that really has no business in the public eye. Conversely, with the rampant secrecy shown by the government, even to the extent of refusing to allow citizens to know who is informing public policy (remember the Vice President’s energy policy meetings?) tools like WikiLeaks are essential if we are not to become a police state.

It would be disappointing if the service were to go away for the long term. WikiLeaks sites in other countries are still on line as of this writing.

Feb

18

I did a security audit a few years ago for a healthcare provider’s IT department. One of the things I pointed out was that while I was asked when I signed in to their facilities for my name and car license plate, nobody asked for picture ID. Additionally, I noted that on several occasions when entering the building, the receptionist had a sign on the desk: “if you need assistance, pick up the phone and dial x…”. When I asked, I was told this person was part-time. Clearly, these folks didn’t feel they needed very good physical security.

You’d think on the other hand, that the federal government, in particular people like the Treasury and the Nuclear Regulatory commission would be more sensitive to the needs of physical security, which is why this article in the Washington City Paper is such an amazing story. This 19 year old mother of two bluffed and blustered her way into very secure facilities doing little more then acting like she belonged there.

Witnesses who later realized they’d seen the thief said she passed muster at the time. The fact that she didn’t have an escort, one secretary reasoned, proved that she belonged in the building. Another employee described the potential suspect as dressing and acting like a typical secretary at the NRC. Those who stopped and questioned her gave up on their suspicions as soon as she started talking.

Her excuses were flimsy inventions. But people don’t like confrontations. They feel they’ve done enough if they ask a question and get an answer.

When I first started out from college, I held a job at a defense contractor, and we were very specifically told that if we found people wandering around who we didn’t recognize, that we should challenge them. We were also told what to do in the event we didn’t get answers that were satisfactory: walk the person to security. I had an occasion once where I encountered a group of visitors in a secured area, and they were without an escort. I knew that one of the VPs had visitors in, so I very cordially asked them whom they were visiting, and escorted them to the VPs office, remarking when I arrived that I had found them without an escort. I didn’t stay long enough to find out if the VP was at all interested in that, or to give him my name.

I’ve seen what it takes to combat this sort of problem, and it’s really only a couple of things:

Following up on that last point, having a single person in charge of an area can be a big help as well. Psychology research shows that people look at others around them to help make a decision. They ask themselves “well, what is Bob doing? He’s not challenging the stranger, so I shouldn’t either.” Unfortunately, Bob is looking around as well, with the same question in mind.

Having a person who is in charge does two things: it means that the person in charge should not be looking at others to decide if they should challenge, and it gives others a person to whom they can address their concerns if they’re uncomfortable challenging by themselves.

Feb

15

Securing WordPress

February 15, 2008 | Leave a Comment

Found online today was this helpful article at Web Design Goldmine on securing WordPress. If you’re a fan of WP (as I obviously am) it’s a good read.

Feb

14

Spreading Fixes by Worm

February 14, 2008 | 1 Comment

Microsoft is researching ways to spread computer fixes by making them more like worms, per this interesting article in The New Scientist.

Milan Vojnović and colleagues from Microsoft Research in Cambridge, UK, want to make useful pieces of information such as software updates behave more like computer worms: spreading between computers instead of being downloaded from central servers.

I’m unsure how I feel about this, but I think it’s mostly negative, and that disappoints me. On the positive side, I think that it’s a cool idea that you’ve got autonomous pieces of software that are making their way around the net, and trying to install themselves on machines. It offloads servers, eliminates the need to go off hunting for fixes, all in all, noble goals.

I think where my concern comes from is that these types of worms are going to make use of the very same types of mechanisms used by the eeeevil worms to spread, or if not, then the eeeevil worms will soon start to masquerade or abuse the new mechanisms provided for the good ones. How do you tell the good guys from the bad guys?

In such an environment, I’d be inclined to disable the services such a “white-hat” worms use to access my systems until I had a good deal more opportunity to study how they really work in the wild. What do you think?

Feb

14

Corporate IT departments are incorporating a new way of meeting corporate IT needs, called Software as a Service (SaaS).  SaaS promises outsourced application management, reduced infrastructure costs, and easily terminated services if needs change. Whether SaaS delivers on these promises is the subject of another post, but it’s certain that SaaS presents some compelling reasons, to both the providers and consumers of services, to adopt cross-domain single-sign on (SSO).

Read more

Feb

12

This will likely be no surprise to regular readers here, you’ve probably already noticed the increased sophistication in web browser attacks. IBM’s X-Force backs up your feeling with numbers, however. IBM is happy to oblige, here you go.

The report is chockablock full of disturbing information on the ways in which the exploits evolved in 2006, complete with attractive graphs and charts to get the points across.

A trend that became prevalent in 2007 was the use of IFrames and other methods of hosting links to malicious content. IFrames make third-party content appear as if it is a part of the URL displayed by the browser, when, in fact, the content within the IFrame is hosted by another server.

Since it has charts and graphs, it’s suitable for showing to your boss to get him to let you go to Black Hat this year.

Feb

12

Humorous Pictures
moar funny pictures

Feb

12

This is an interesting take on applying technology to solve a technology problem. This article on ITWorld’s site covers a panel discussion about the risks created by encrypting data.

“Risks caused by encrypting?”, you say, “I thought that was supposed to make things better!” The article points out that encrypting all your data could be a risky idea. If someone is able to compromise your keys somehow, all your data is now held hostage while you work out how to pay them.

“Organizations experienced with encryption are standing back and saying this is potentially a nightmare. It is potentially bringing your business to a grinding halt.”

It just goes to show that there’s no single silver bullet, and you have to weigh the risks vs. the payoffs for everything related to security.

Feb

12

This post over on 0×000000 talks about the newly released Firefox 2.0.0.12 being vulnerable to a security compromise, as reported by Slashdot in this article. The NoScript plugin (which you should be running, incidentally) helps with this problem, apparently.

There’s some disagreement between Ronald and the Mozilla developers as to whether this is in fact a problem, and if so, whether it’s a big one. So far, the discussions have not come to conclusion, but it’s another example of assessing risks before determining whether you should fix them, which I just wrote about. It’s funny how these things happen in groups.

Feb

12

Slashdot is running this article on a flaw found in OpenBSD’s implementation of their pseudorandom number generator (PNRG). This number generator is used by the implementation of a number of network services on OpenBSD, and from there its found its way into a number of other *NIX implementations, including Darwin/MacOS X, FreeBSD, and NetBSD. Most of the implementations other than OpenBSD have committed to fix this bug, although Apple isn’t committing to when. Knowing what “random” number is going to come up next permits some exotic exploits that allow an attacker to compromise security. The question at hand isn’t whether this fault exists, it’s how important is it.

OpenBSD’s maintainers have decided that the bug is academic, and doesn’t represent a real enough threat to fix. This puts the debate squarely into interesting territory for me. I’m a pragmatist, and I think that the development activities you perform (and this includes fixing a bug) have to be related to their real value. I classify a bug in the category of “risk”, which means I use a two-part formula to determine how important it is to address.

Although many professionals don’t realize it, risks (and this includes bugs) have two dimensions, severity and probability. Probability is frequently given short shrift, and the focus is all on it’s more glamorous relative, severity. Priority is however a factor of these two dimensions.

For example of this principle in action, we need look no further than the example at hand: the PNRG generator in OpenBSD. The argument made by the maintainers is that the probability is low enough that regardless of how severe the consequences of the exploit, the chances that it will or can be exploited are low enough that the overall priority is low. This is a questionable assumption with an open source project such as OpenBSD, and with the amount of attention that this particular bug can get.

Developers, and their subspecies crackers, are a somewhat arrogant lot (and I include myself in that bucket, before anyone gets upset). If you tell us that we can’t do something, that usually is just blood in the water. Knowing that this exploit exists, even if we have to work really hard to get to it, well, we’ll try to figure out a way anyway. This adds to the probability, simply because there are so many of us out there. Additionally, the knowledge of this weakness is easily obtained, which also lowers the barrier to entry, again increasing the probability.

There’s always the possibility that someone else will fix the problem and contribute it to the OpenBSD community, since this is open source, but if the maintainers refuse to integrate a contributed fix, that could result in a fracture of the code base, and that isn’t good for anyone.

Time is the only way that we will tell whether the OpenBSD maintainers are correct in their assessment of the probability, and thus the risk involved with this PNRG bug. If proof-of-concept or actual exploits appear for this in the wild, then the maintainers may have little choice except to integrate a fix, or to suffer people moving to other BSD variants that don’t have the same flaw.

« go back — keep looking »

Blogroll

WP Themes