Category: Security

Posted on

Security Lessons from Dick Marcinko

In January, [Dick Marchinko](http://www.dickmarcinko.com/) spoke to my company. Here are some of the lessons that I drew from his hard-to-follow speech:

Most importantly, he said, there is no substitute for human intelligence.

Attackers can…

1. defeat security systems, such as locks, by replacing them with their own security system in advance of a break-in. Security response will trust in their security system to help catch or contain attackers, not realizing that it was replaced and turned to the service of the attacker.
1. use decoys to mislead security response. For example, crews might diffuse one bomb, and they forget to look for a second one.
1. attack during noisy, chaotic, busy times, like shift-change. (My note: Hackers like to hide their malware on busy networks and on busy file servers, such as in university or ISP networks.)
1. trip alarms to assess response capabilities. Once assessed, booby-trap the response capabilities so they are ineffective.
1. evade security systems. TSA secures airports from passengers, but what about security airport construction sites and access? America’s ports and waterways are largely unprotected.

Posted on

Javascript = poor security

Jake Edge writes about “[Web security vulnerabilities and Javascript](http://noscript.net/)”:

> Various recent, unrelated security issues seem to have a common thread: Javascript.

This has been true for the past several years, and it’s not restricted to Javascript — it has happened with Flash. Our browsers suck down executable code from nearly every web site we visit, and run it. It enables a richer web browsing experience. Although JavaScript, and to a lesser extent, Flash, are somewhat restricted in what they can run on our computers, it opens the potential for abuse. And they have been [abused](http://www.securityfocus.com/news/11501), [again](http://www.darkreading.com/document.asp?doc_id=143840) and [again](http://www.networkworld.com/news/2007/040207-javascript-ajax-applications.html).

What solutions exist?

1. Stick head in sand.
3. Wait for web site owners and browser manufactures to fix the security problems. And wait. And wait. And wait some more.
2. Use Firefox and the [NoScript](https://addons.mozilla.org/en-US/firefox/addon/722) extension, which disables JavaScript, Flash, Silverlight and other executable code from running. It’s easy to enable JavaScript when needed.

[NoScript](https://addons.mozilla.org/en-US/firefox/addon/722) can turn web browsing into a painful experience. Some web sites don’t function properly without JavaScript enabled. Functionality breakage may be subtle. I once bought movie tickets for the wrong day because I had JavaScript disabled. I still use NoScript.

[NoScript](https://addons.mozilla.org/en-US/firefox/addon/722) has advantages beyond security: I see fewer annoying animated ads, making many web sites more readable.

Posted on

Internet Explorer more secure than Firefox?

In the past, I’ve recommended to friends and family that they run Firefox instead of Internet Explorer to gain better security and usability on Windows systems. I’m re-evaluating that stance now that I’ve learned about a new feature of Windows Vista that restricts Internet Explorer and runs it inside of a jail. It’s called [Protected Mode](http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx), or [Mandatory Integrity Control](http://www.securityfocus.com/infocus/1887/2), and it means that that spyware and adware are less likely to infect a Vista computer.

As far as I know, Firefox doesn’t (yet) run inside the “jail”, so Internet Explorer is probably the more secure choice — yet another reason to admire the technical engineering [effort that went into Windows Vista](http://en.wikipedia.org/wiki/Windows_Vista#New_or_improved_features).

Despite the improved security of IE 7 in Vista, I enjoy the usability of Firefox, including the ability to disable JavaScript from running by default, using the [NoScript extension](https://addons.mozilla.org/en-US/firefox/addon/722) extension. Does anyone know whether there’s a [NoScript extension](https://addons.mozilla.org/en-US/firefox/addon/722) available for Internet Explorer? If not, I’m sticking with Firefox.

Posted on

FreeNX and SELinux

As I [mentioned earlier](http://jaredrobinson.com/blog/?p=87), upgrading from Fedora 6 to Fedora 7 broke FreeNX. A temporary solution was to disable SELinux. Here’s what allowed me to re-enable SELinux. First, I read the RHEL 5 SELinux guide to [building a local policy module](http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/sec-sel-building-policy-module.html). Next, I ran the following commands, as root:

setenforce Enforcing
/etc/init.d/auditd stop
mv /var/log/audit/audit.log /var/log/audit.log.old
/etc/init.d/auditd start

At this point, I used an NX client to attempt to connect to my server, which failed. Then I did this:

cd /etc/selinux
cat /var/log/audit/audit.log | audit2allow -M freenx
semodule -i freenx.pp

At that point, my NX client allowed me to connect to the server. Here’s the freenx.te file that audit2allow created:

module freenx 1.0;

require {
type unconfined_t;
type lib_t;
class file execmod;
}

#============= unconfined_t ==============
allow unconfined_t lib_t:file execmod;

Posted on

Security quotes

“Security systems are never value-neutral; they move power in varying degrees to one set of players from another.” — Bruce Schneier, Beyond Fear p. 35

“People exaggerate spectacular but rare risks and downplay common risks”. — Bruce Schneier, Beyond Fear p. 26

“Technology is generally an enabler, allowing people to do things. Security is the opposite: It tries to prevent something… That’s why technology doesn’t work in security the way it does elsewhere, and why an overreliance on technology often leads to bad security, or even to the opposite of security.” — Bruce Schneier, Beyond Fear p. 13

Posted on

Stages of Security in the life of computer software

Is your client-server software secure? You may be surprised to find that even mature software, sporting the use of standard encryption, could be putting your mission-critical data at risk. Why is that? It has to do with economics and the lifecycle of software. Here are the stages.

Prototype. No one cares about the security of the client-server communication.

First release. Althought the system (likely little more than an improved prototype) has been shipped, it may not be usable, and if it is, it lacks mission-critical features. Security is low on the priority list. If encryption and authentication were implemented, it is most likely minimal, brittle and insufficient. If the security is robust, the product is not functional and likely never will be because the ISV will go out of business.

Second or third release. If the ISV has survived long enough to release a second or third version, customers likely demanded the use of standard encryption. In the old days (the 1990s), this means the ISV would have switched from XOR “encryption” to DES or 3DES. These days, standard encryption probably means use of SSL/TLS without certificate checks. Note that customers probably won’t ask about the security of the authentication mechanisms.

Unfortunately, use of a standard encryption algorithm doesn’t mean communication is secure. Software is likely to be vulnerable to man-in-the-middle attacks and have authentication bugs. The customer isn’t likely to know this, and neither is the ISV. If the ISV does know, they won’t fix the problems. This shouldn’t be surprising — the risk tolerance is different for the ISV versus their customers. The software vendor isn’t the one that is going to suffer losses due to information disclosure or breach of integrity.

At this stage, customers usually apply more pressure to implement new features than to focus on security. Of course, this is based on ignorance of the actual situation. The vendor isn’t likely to want to pay the price to improve security… unless the customer knows and applies pressure to get it fixed.

Eventually, a security-conscious customer (i.e. a financial institution or a government) hires someone to evaluate the software, and they start asking hard questions of the ISV. Most of the ISV’s software engineers won’t know the answers because the security mechanism is transparent to their daily work — it stays out of sight, and out of mind. Eventually, people figure out that the encryption is vulnerable to man-in-the-middle attacks or authentication bugs. At first, customers may be reluctant to believe that the security holes are serious, and then they will panic. They will apply pressure to the ISV to get it fixed.

Take-away points:

  • SSL without certificate checks is vulnerable to Man in the Middle attacks.
  • Almost no ISV gets encryption right the first time, and they won’t fix problems unless their feet are held to the fire.
Posted on

Best of Breed, or Best of Mediocrity?

Having worked for some time as a software engineer in the enterprise security
software world, I know that customers (enterprises) look for “best of breed”
software. For a large company customer, this usually means that a software
solution distinguishes itself in some way that makes it work well in their
environment. Often, this translates to reliability, cross-platform support,
person-to-person support and the ability to function beyond what is advertised.

As many are aware, there is “consolidation” going on in the security market.
Big fish are swallowing smaller fish, and it’s lucrative, in the short term,
for everyone except customers. Supposedly, the consolidation means that two
separate products can be “integrated”, or unified. Never mind the previous
competitive relationship that may have existed between the product teams and
their management. For some reason, people seem to think that competition
evaporates and that the two product teams will happily work together to build
the next generation “Best of Breed” software solution.

Not so.

In any big corporation or software company, there are constant power plays
being made. You could call this “decision making”, and if you have uncommonly
good leaders, you might even say good decisions are being made.
Unfortunately, it is human nature for most people to misuse and abuse positions
of power. Instead of making product decisions that are best for their merged
customer base, they make decisions that keep themselves in a position of power.

So, we have two best of breed products: Overdog and Underdog. Underdog is
easier to manage, but isn’t as complete in its offerings. Overdog is more
complete, but is more expensive to deploy and manage. Overdog has the advantage
of being used in Fortune 500 companies. Underdog, on the other hand, is trying
to break into that market space.

Enter Big Fish — a.k.a. Consolidator. Consolidator buys Overdog, and a few
years later, buys Underdog. We take two products, both “Best of Breed” in
different ways, and expect to see them merged together to make something “next
generation” — better, faster, stronger, and easier to use.

Whenever there is a consolidation, talented people get fired, and their
creative ideas and abilities are lost. Product integration never happens as
easily as anyone would like to believe (if it happens at all). And in the end, customers end up with a
product that we can best label as “Best of Mediocrity”. Consolidation means
that customers lose their “Best of Breed” solutions.

What can you expect from Software Consolidators? Mediocre solutions. Look
elsewhere for excellence.

Posted on

The purpose of security…

A coworker made these assertions about security. I think they’re worth repeating:

  • The purpose of security is to establish accountability of an individual.
  • The purpose of auditing is to verify the trust that has been placed in an individual.
Posted on

Is Data Mining Fools Gold?

Here’s a thought provoking article about the problems of large-scale data mining by
governments. It’s written by a person living in the UK.

“Data-mining is complicated, and the more data you are mining, the more
false positives your software will throw up. If you act upon a false
positive for a motoring offence, it’s an inconvenience for the motorist,
but for an alleged case of child abuse, it can rip the family apart and
ruin the child’s life.”

“Furthermore, gathering large amounts of data is inherently dangerous.
Whatever information governments find interesting will also draw the
attention of criminals. Databases can be hard to keep secure, and it’s
not necessarily hackers that we should be worried about, but
unauthorised access by employees of the agencies that use these
databases. Equally, the more data you have, the more difficult it is to
maintain accuracy. In 2000, an audit of the Police National Computer
found that 86% of records contained errors, 85% of those errors were
serious, and some were libellous.”

“Technology can be a very powerful tool, but what it can’t do is replace
real human beings or traditional investigative work. Designed badly or
used poorly, databases are the technological equivalent of fools gold.”

Posted on

Mongrel web server

Here’s an interview with Zed Shaw, the author of the Mongrel web server — a web server for the Ruby programming language that is good for use in combination with Ruby on Rails and other Ruby-based web-app frameworks. It’s interesting in that it’s fast, secure, cross-platform, and it’s not a heavyweight solution (compared to Apache). Why is it more secure than Apache at the HTTP protocol level? Mongrel utilizes the Ragel State Machine Compiler
 to generate the protocol parser, “and that is very strict and seems to block a huge number of attack attempts simply because it is so exacting.”