Liudvikas Bukys

Looking for needles in enormous bulky repetitive haystacks? Many logfile reduction programs require investment in tuning and tweaking. In contrast,
SLCT, the Simple Logfile Clustering Tool is useful right out of the box, with no tuning for specific logfile formats; it figures things out on its own. I was going write something just like it (a generalization of previous logfile reducers I have done), now I can instead plan on improving on something that’s already pretty darned good (and fast and memory-conserving too).

[via the handy site LogAnalysis.Org]

Paul Vixie shares his Thoughts About “Protection Against BIND”,
in which he reacts to the latest
SANS Top 20 Vulnerabilities List, pointing out that there
are no recent exploits, some of the configuration advice is lame or worse, and dDoS attacks on otherwise secure software is not a “vulnerability”.
While the SANS Top 10 and Top 20 lists have always been useful awareness tools and helpful basic guidance, there is always a tendency in a complex field for consensus guidance to turn to overgeneralized mush. Intelligent criticism like this is a good thing.

I happened across web site of Victor Yodaiken who had some piquant remarks on security
(“Someone made serious money from construction of the Maginot line.”) and
the Common Criteria (giving a beautifully clear example of how they might be translated into plain acronym-free English). Now if only he published an RSS feed; I don’t know of a currently-open public scraper (myRSS is not accepting new feed requests).

Mark J Cox: Survivability:

So a full install of a Red Hat Enterprise Linux 3 box that was connected to the internet in November 2003 even without the firewall and without receiving updates would still remain uncompromised (and still running) to this day.

It’s not to say that a RHEL3 user couldn’t get compromised – but that’s not the point of the survivability statistuc. In order to get compromised, a user would have to have either enabled anonymous rsync, SWAT, or be running an open CVS server, none of which are default or common. Or a user would have to take some action like visiting a malicious web site or receiving and opening a malicious email.

• This is an unhappy conversation on many many levels:
  

  AKMA:

  The officer in question (whose conduct was entirely professional, firm, and calm behind those mirrored shades) solemnly assured me that in order to use the library’s open wireless signal, I had to be seated within the library. The officer then wandered on back to the nearby police station.

  …

  ‘Maybe if you had permission it would be all right, but it’s a new law, sir; ‘theft of signal.’ It would be like if you stole someone’s cable TV connection.�

  …

  ‘It’s a federal law, sir; a Secret Service agent came and explained it to us.’
  
  [via Blogos]

• The comments on the article above include the useful link EFF: Best Practices for Online Service Providers that advocates minimizing legal problems by minimizing information collection.
• Having had to dig hard to track down aggressive intruders, I also worry about lacking the ability to investigate attacks on infrastructure (mine or everybody’s). While this application of “theft of services” looks bogus, it is a tool that I’d like to have when somebody is really attacking my network or systems. Meanwhile, there is a permanent tension between knowing what’s happening on your network (say, if you’re an ISP tracking botnets) and maintaining ignorance as a legal defense.

James Lick: Tracking A Zombie Army (PDF)

[via Asrg]

International Standard ISO/IEC 17799:2000 Code of Practice for Information Security Management Frequently Asked Questions (November 2002):

ISO/IEC 17799: 2000 is a management standard, and deals with an examination of the non-technical issues relating to installed IT systems. These issues have to do with such matters as personnel, procedural, and physical security, and security management in general.

The Common Criteria standard is a technical standard. It is intended to support the specification and technical evaluation of IT security features in products. Normally, the products are evaluated as part of the development/production cycle. The Common Criteria standard also has a major usage as a structure, syntax and catalog of information technology specifications that can be used to describe user technical requirements for security in products.

…

The current US position is strongly in favor of the major revision of the [17799] document, which is currently underway. While there was no official US government position expressed, US TAG members from both the Commerce Department (via NIST) and Department of Defense (via the Defense Information Systems Agency) supported the US position.

Rogue/Suspect Anti-Spyware Products & Web Sites
[via Diary Date]
See also some dissent about the specifics.

The problem is the bad platform.
The symptom is the miserythat so many users are living with.
The cottage industry for solutions is better than nothing, but it’s still a mess.

Jim Chow, Ben Pfaff, Tal Garfinkel, Kevin Christopher, Mendel Rosenblum:
Understanding Data Lifetime via Whole System Simulation:

We have used TaintBochs to analyze sensitive data handling in several
large, real world applications. Among these were Mozilla, Apache,
and Perl, which are used to process millions of passwords, credit card
numbers, etc. on a daily basis. Our investigation reveals that these
applications and the components they rely upon take virtually no measures
to limit the lifetime of sensitive data they handle, leaving passwords
and other sensitive data scattered throughout user and kernel memory. We
show how a few simple and practical changes can greatly reduce sensitive
data lifetime in these applications.

[via Justin Mason]

Jack Shafer in the Slate article
E-mail Confidential – Who’s afraid of Time Inc.’s legal disclaimer? has his attorney dissect an email disclaimer in detail.

This boilerplate proliferates because professionals
in the legal, auditing, and security consulting industries
feel compelled to recommend its use.
Unfortunately, the ratcheting ever-more-onerous language that
gets accreted by these things for cover-your-butt reasons results in most of them being statements that are intellectually ridiculous, legally dubious, and rude.

At this point, consulting professionals should be embarrassed to recommend this stuff.

[via Jeff Nolan via Techdirt]