By Ira Winkler

I was finishing up my latest book, Zen and the Art of Information Security, and I was thinking about what was the most important component of a security program. The one thing that I kept coming back to is that an organization that the most secure organizations were those that ignored the source of the problems and focused on addressing the problems.

Continue Reading »

By Jim Reavis 

There has been an evolution in my thinking about the security appliance.  The high performance, purpose-built, rack-mounted boxes that supposedly turn security into “the blinking lights” don’t solve everything, but they do certain things very well and in some cases are a big improvement over onerous software alternatives.  When a security task must be performed quickly, more often than not it is the appliance that rises to the occasion.  I have often characterized the appliance at the top of security process maturity models: a security process is defined and made repeatable, at some point the process is automated in part or in whole with software, later, the appliance makes this process even more efficient.  Appliances are great, they are improving apace with Moore’s Law, they just aren’t what they used to be.

Continue Reading »

By Ira Winkler

At the recent RSA Conference, I witnessed a security “luminary” doing something that bordered on the despicable. I am not going to name the person, because maybe he was having a bad day and I too have had some bad days. However from a security perspective, the behavior was unacceptable.

Basically, this person had a roller board suitcase with him and a security guard tried to stop him as he went to the escalator down to the exhibition level. If you weren’t at RSA, I will tell you that the security guards were generally older, apparently retired people looking for extra income. This guard was a very small, senior citizen. The security luminary was on his cell phone and appeared to be blatantly and purposefully ignoring the guard trying to stop him. As the guard tried to stop him, he almost knocked her over as she was attempting to diligently doing her job. Frankly, if the situation were to progress, it could have been a basis for an assault charge.

As he refused to stop and went down the escalator, she was just repeating to herself that she was going to lose her job. Luckily she saw a police officer and reported the incident to him so that the responsibility was now moved to law enforcement. All the guard wanted this “luminary” to do was check his suitcase at the bag check, which was literally 10 feet away.

An inconvenience, yes. However the fact is that the guard was attempting to enforce security regulations like they were supposed to. Do you know how rare that is? As we are surrounding by guards, who do little more than take up oxygen, it is refreshing to see a diligent guard. Instead, this person treated the guard without respect, jeopardizing their job, and most importantly, ignoring a security policy.

Treating anyone without any morsel of respect is just rude. However when you are a security professional, ignoring security policies is inexcusable. You may not like them, but if you ignore physical security policies, you are sending a message that it is ok to ignore security policies as a whole. Why should anyone adhere to your information security policies, if you demonstrate that it is ok to arbitrarily ignore other security policies?

If you don’t like a security policy, find someone to complain to. However to purposefully ignore the policy, and being part of demoralizing a security guard, who is just doing their job is inexcusable.

By Kurt Seifried (kurt@seifried.org)

People often argue that software doesn’t decay, or to quote an Op-Ed piece from the New York Times:

The software industry’s sluggishness is not just a reflection of the vagaries of the economic cycle. It is a manifestation of a fundamental, if often overlooked, characteristic of the industry’s product: software never decays. Machinery breaks down, parts wear out, supplies get depleted. But software code remains unchanged by time or use. In stark contrast to other industrial products, software has no natural repurchase cycle.

But this simply isn’t true (never has been, never was). Software decays, much like a radioactive element, some decay rapidly, and some decay very slowly. For example accounting software that implements tax rules may become obsolete within a year due to changes in the tax code. Customer service management software can decay rapidly due to changes in the way customers are handled, the products offered, and so on. Conversely some software packages decay very slowly, avionics software for example often lasts for decades, and some operating systems have also withstood the test of time.

However it is very rare that a single event will cause software and operating systems to suddenly jump forward in their decay rate, however this can and does happen.

Continue Reading »