A recent Twitter post by Team Cymru pointed at a (very brief) debate about the value of security awareness training.  It’s an issue that has concerned me for a long time.

I got interested in security starting with research into viruses and malware.  Early on, I did a lot of work reviewing the various available products.  In the responses I got to my efforts, one point was abundantly clear: everyone, almost without exception, was looking for the “perfect” antivirus.  Even though Fred Cohen had proven that such an animal could not possibly exist, everybody wanted something they could “set and forget.”

Notice two things.  The first is that perfect security doesn’t exist.  As (ISC)²’s marketing phrase has it, security transcends technology.  The second point is that people aren’t particularly keen on learning about security.  They fight against it.  They have to be motivated into it.  And that motivation tends to be individual and personal.

Which means security awareness training is hard, and individual, and therefore expensive.  Expensive means that companies are loath to try it, in any significant way.  Hundreds of thousands or millions of dollars can be spent on a raft of security technologies, but security awareness programs can only get a budget of a few thousand a year.  Which means they can’t be individual, which means they won’t work very well, which means companies aren’t willing to try them.

The default position people take is to resist security awareness.  They don’t want to know extraneous stuff.  They just want to get on with their jobs.  So, even if you were to produce a really good security awareness program, there would undoubtedly still be some who would resist to the end, and not learn.  They wouldn’t benefit from the program, and they would still make mistakes.  So security awareness training won’t be perfect, either.  Sorry about that.

However, I’ve noticed something over the years.  I get asked, by all my friends and acquaintances, for advice about virus protection, and home computer protection.  Some learn the ins and outs, the dangerous activities, the marks of a phishing email message.  They never ask me to clean their machines.  Some just ask about the “best” antiviral software.  Usually after they’ve asked me to clean off a computer.  I identify what they’ve got, and tell them how they got it.  You shouldn’t [do music sharing|do instant messaging|go to all those weird Websites|open attachments you receive] I tell them.  They always have reasons why they must do those things.  (Not very good reasons, mind you, just reasons.)

You know that old medical joke about “Doctor, it hurts when I do this” “Well, do do that”?  It’s not funny.

People ask me what antivirus program I use at home.  Very often I don’t use one, unless I’m testing something.  (At the moment I’m testing two, and I’m about ready to take both of them off, since both of them can be real nuisances at times.)  There are long periods where I run without any “protection.”  I know what not to do.  My wife knows what not to do.  (After all, she read my first book seven times over, while she was editing it.)  We don’t get infected.  Not even by “zero days” or “advanced persistent threats.”

Security technology isn’t perfect.  Security awareness training isn’t perfect.  However, at present, and for as long as I can remember, the emphasis has been on security technology.  We need to give awareness more of a try.

Is security awareness “worth it”?  Is security awareness “cost effective”?  Well, we’ve been spending quite a lot on security technologies (sometimes just piecemeal, unmanaged security technologies), and we haven’t got good security.  Three arguments in favour of at least trying security awareness spending:

1)  When you’ve got two areas of benefit, and you are reaching the limits of “diminishing returns” in one area, the place to put your further money is on the one you haven’t stressed.

2)  Security awareness is mostly about risk management.  Business management is mostly about risk management.  Security awareness can give you advantages in more than just security.

3)  Remember that the definition of insanity is trying the same thing over and over again, and expecting a different result.

BKABVCLD.RVW   20110323

“Above the Clouds”, Kevin T. McDonald, 2010, 978-1-84928-031-0,
UK#39.95
%A   Kevin T. McDonald
%D   2010
%G   978-1-84928-031-0 1-84928-031-2
%I   IT Governance
%O   UK#39.95
%O  http://www.amazon.com/exec/obidos/ASIN/1849280312/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/1849280312/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/1849280312/robsladesin03-20
%O   Audience n+ Tech 1 Writing 1 (see revfaq.htm for explanation)
%P   169 p.
%T   “Above the Clouds: Managing Risk in the World of Cloud Computing”

The preface does a complicated job of defining cloud computing.  The introduction does provides a simpler description: cloud computing is the sharing of services, at the time you need them, paying for the services you need or use.  Different terms are listed based on what services are provided, and to whom.  We could call cloud computing time-sharing, and the providers service bureaus.  (Of course, if we did that, a number of people would think they’d walked into a forty-five year time-warp.)

The text is oddly structured: indeed, it is hard to find any organization in the material at all.  Chapter one states that the cloud allows you to do rapid prototyping because you can use patched operating systems.  I would agree that properly up-to-date operating systems are a good thing, but it isn’t made clear what this has to do with either prototyping or the cloud.  There is a definite (and repeated) assertion that “bigger is better,” but this idea is presented as an article of faith, rather than demonstrated.   There is mention of the difficulty of maintaining core competencies, but no discussion of how you would determine that a large entity has such competencies.  Some of the content is contradictory: there are many statements to the effect that the cloud allows instant access to services, but at least one warning that you cannot expect cloud services to be instantly accessible.  Various commercial products and services are noted in one section, but there is almost no description or detail in regard to actual services or availability.

Chapter two does admit that there can be some problems with using cloud services.  Despite this admission some of the material is strange.  We are told that you can eliminate capacity planning by using the cloud, but are immediately warned that we need to determine service levels (which is just a different form of capacity planning).  In terms of preparation and planning, chapter three does mention a number of issues to be addressed.  Even so, it tends to underplay the full range of factors that can determine the success or failure of a cloud project.  (Much content that has been provided previously is duplicated here.)  There is a very brief section on risk  management.  The process outline is fine, but the example given is rather flawed.  (The gap analysis fails to note that the vendor does not actually answer the question asked.)  SAS70 and similar reports are heavily emphasized, although the material fails to mention that many of the reasons that small businesses will be interested in the cloud will be for functions that are beyond the scope of these standards.  Chapter four appears to be about risk assessment, but then wanders into discussion of continuity planning, project management, testing, and a bewildering variety of only marginally related topics.  There is a very terse review of security fundamentals, in chapter five, but it is so brief as to be almost useless, and does not really address issues specifically related to the cloud.  The (very limited) examination of security in chapter six seems to imply that a good cloud provider will automatically provide additional security functions.  In certain areas, such as availability and backup, this may be true.  However, in areas such as access control and identity management, this will most probably involve additional charges/costs, and it is not likely that the service provider will be able to do a better job than you can, yourself.  A final chapter suggests that you analyze your own company to find functions that can be placed into the cloud.

Despite the random nature of the book, the breadth of topics means it can be used as an introduction to the factors which should be considered when attempting to use cloud computing.  The lack of detail would place a heavy burden of research and work on those charged with planning or implementing such activities.  In addition, the heavily promotional tone of the work may lead some readers to underestimate the magnitude of the task.

copyright, Robert M. Slade   2011     BKABVCLD.RVW   20110323

Today when I signed on I got a bit of a shock.  The computer warned me that my password was going to expire in 5 days, and I should probably consider changing it.

It was a shock because this is my computer, and I go along with current password aging thinking, which is that a) we can’t figure out who first figured that password aging was all that hot an idea, and b) if it ever was a good idea, in the modern computing environment, password aging is a non-starter.  Given that passwords should probably exceed 20 characters, and likely should be somewhat complex, trying to get people to choose a good one more than once every few years (when rainbow tables have been extended) is likely more security compromising than enhancing.

So, I went looking.  Having dealt with security for a number of years, it wasn’t too hard for me to figure out that I didn’t want the control panel (since I hadn’t seen anything along that line while I was modifying other settings), and that I likely wanted “Administrative Tools,” and under that “Local Security Policy.”  I had to read through all the options to determine that I probably wanted “Account Policies,” but, under that, it was obvious I wanted “Password Policy,” and, once there, “Maximum password age” stood out.  With no particular options or actions I went back to the menu bar until I found that “Action” had a “Properties” function, bringing up a dialogue box with an entry box with a number in it.  I figured that setting it to zero might turn off password aging, but I didn’t want to do anything that might require me to set a new password every time I signed on, so, when I saw that one of the tabs was “Explain,” I choose that.

(Allow me to digress for just a second here, and note that I suspect that the average home or small office user would not have found it easy to find this setting, and thus would have been stuck with the default.  And all that that implies.)

The explanation did confirm that setting the number of days to zero does mean the passwords never expire.  But it also told me that “It is a security best practice to have passwords expire every 30 to 90 days, depending on your environment. This way, an attacker has a limited amount of time in which to crack a user’s password and have access to your network resources.”

Microsoft, you’ve got to be kidding.  If an attacker has enough access to your system in order to start cracking your passwords, then they’ll almost certainly succeed within a few days.  Unless you’ve chosen a really, really good password, in which case it might be some years.  So 30 to 90 days makes very little sense.  (And, if you’re really serious about the maximum of 90 days, how come the entry box allows up to 999?)

But then, right down at the bottom, it tells me that “Default: 42.”

Oh, sorry, Microsoft.  Obviously you are kidding.  Nobody could take that seriously as a default.

(But then, why is that the default, and why is it enabled by default? …)

The issue prompted a little more thinking on my part.  Was it really 37 days (42 minus 5) since I’d installed the machine?  Ah, but then, it couldn’t be.  As previously noted, I had to take it back to the store to clear up some OS registration issue.  They, of course, didn’t ask what password I’d set, they just blew off the passwords.  So, the 37 days would start from that point, wouldn’t it?

Well, apparently not.  When I checked my journal, it was obvious that the 37 days started when I first started setting up the computer, not when the store eliminated the passwords.

Interesting version of “history” there, Microsoft …

At a local conference, one presenter had a topic of “Blow Your Own Horn.”  The point was to be ready with some kind of success story (any kind of success story) ready for presentation.  Elevator pitch level stuff, except you aren’t selling anything specific, just success.

For example: “Last year you (the Board) approved purchase of a $50,000 licence fee for AV software on the email server.  This past month, records show it stopped 1 million viruses, which would otherwise have gotten through.  Had they been run, they would have cost $500 each (estimated industry average) to clean up.  Therefore, your prescient decision to spend $50,000 has returned $500,000,000 to the company.”

(OK, yes, any infosec professional knows the holes in that logic.  And you are turning it so that you are creditting the Board with what should be *your* success.  But you get the idea.)

I suggest everybody have a file in some readily accessible drawer, for scribbling down any idea you come up with along these lines, using company specific data.  One idea per page.  Any time you get called to the Boardroom (or, depending upon how many ideas you can come up with, any meeting) grab a sheet and read it in the elevator.  Whatever they asked you to talk about, walk in and start off with, “Thank you for your interest in X.  Before I begin, I’d like to let you know that, because of our investment in a $2,000 course in Ethereal, for one of the net sec admins, last April’s intrusion was detected within 5 hours, and we were able to ensure that all servers were hardened against that particular attack within only a further 12 hours, all within house.  Normally such an attack would be undetected for three days, and would have required outside help at a usual cost of $7,000.”

(Yes, this gets down into the weeds in regard to architecture, but security is a lot more about politics than technology.  And people love stories.)

Well behaved anitvirus programs can safely work together in peace and harmony.

Unfortunately, relatively few AVs are well behaved.

On my new desktop, I’ve got Avast (came with the machine, has a free version, and is a pretty good product) and MSE (it’s free, and it’s pretty safe for most users, although, as a professional, some parts of it irk me).  I’ve set both to ignore the virus zoo, although they aren’t too good at taking that restriction to heart.

MSE quarantined a few samples before I got things tuned.  Of course, it doesn’t have any function to get stuff out of “quarantine.”  (As I say, as a professional this is irksome, but, considering the average user, I’d say this is a darn good thing.)

Today Avast gave me a warning of some dangerous files.  They were the ones MSE quarantined.

(In case anyone is interested, the quarantine seems to be in \ProgramData\Microsoft\Microsoft Antimalware\LocalCopy.)

We’ve had means of expressing our opinions on various things for a long time.  Amazon has had reviews of the books pretty much since the beginning.  But how do we know that the reviews are real?  Virus writers took the opportunity presented by Amazon to trash my books when they were published.  (Even though they used different names, it only took a very simple form of forensic linguistics to figure out the identities.)

More recently, review spam has become more important, since many people are relying on the online reviews when buying items or booking services.  A number of “companies” have determined that it is more cost effective to have bots or other entities flood the review systems with fake positive reviews than it is to make quality products or services.  So, some nice people from Cornell university produced and tested some software to determine the fakes.

Note that, from these slides, there is not a lot of detail about exactly how they determine the fakes.  However, there is enough to indicate that sophisticated algorithms are less accurate than some fairly simple metrics.  When I teach about software forensics (aspects of which are similar to forensic lingusitics, or stylistic forensics), this seems counterintuitive and surprises a lot of students.  Generally they object that, if you know about the metircs, you should be able to avoid them.  In practice, this doesn’t seem to be the case.  Simple metrics do seem to be very effective in both forensic linguistics, and in software forensics.

The other night Gloria asked me what to do about securing the computer if I die first.  (Yes, we talk about those type of things.)  I really didn’t know what to tell her.  And told her that.

A decade ago, I would have had a list of things to do.  Actually, she knows that list: although she always considers herself ignorant about computers, she’s actually more savvy than most (and a lot more savvy than she gives herself credit for).  But these days I hardly know where to start.  You have to qualify every piece of advice you give, and you have to constantly keep up on the latest attacks and threats.  General classes don’t cut it any more.

This isn’t because the attackers are getting any more imaginative.  In general, they aren’t.  Recently a lot of companies (some, like RSA and Sony, very high profile) have been screaming about getting hit by APT (Advanced Persistent Threat) attacks.  What is APT?  Simply social engineering and malware.  Well, since malware has almost always had a social engineering component, I suppose it’s really only malware.  We’ve had malware for thirty years.  So what’s new?  Nothing.  The companies were sloppy.

What is happening is that all of information and communications technology is getting more and more complex.  Programs are tied into the operating system.  Nothing is clear cut.  The actual workings of the system are hidden from the user.  Hardware is virtual.  Networks are cloudy.  Gene Spafford mentioned this in a recent interview.  Since it was an interview, he really didn’t get a chance to expand on this point: the interviewer was more interested in trying to nail down who to blame for the situation.  Who is to blame?  Well, the vendors are creating sloppy systems: forfeiting security in the name of bells and whistles.  But that, of course, is because only a vanishingly small segment of the population is actually interested in security: everyone wants dancing pigs.

I’ve written before about complexity and security.  (And network complexity.)  But every day brings new examples.  Today, for example, Adobe has finally brought out an easier way to delete or manage Flash cookies.  Flash cookies are a particularly pernicious and tenacious form of cookie.  Those of you who think you are “up” on security may have set your browser to delete cookies.  Good.  Unfortunately, it doesn’t do a thing for Flash cookies.  So, Adobe has finally given us control over Flash cookies.  In version 10.3.  What version of Flash do you have?  Do you even know?  How would you find out?  It took me quite a while, and I know what I’m doing.  And, in spite of the fact that I’ve had numerous (annoying) Adobe updates recently, I don’t have 10.3.

I’m supposed to be a specialist not only in security, but in security awareness.  And the job is just getting overwhelming.

It’s really depressing.

Once again, in a month and a half, Shaw has disabled my outbound email.

For no particular reason.

Oh, sure, the error code says 554, rejected due to poor reputation.  So, like before, I do a lookup.  (For those interested in the stability of DHCP, my IP address is still the same, a month an a half later.  Even after being away for two conferences, and a short vacation.)  So, once more, I look up http://www.senderbase.org/senderbase_queries/detailip?search_string=70.79.166.169

This time there is even less information.  Google groups, SpamCop, dnsbl.njabl.org, bl.spamcop.net, cbl.abuseat.org, sbl.spamhaus.org, and pbl.spamhaus.org all say I’m clean.  (dnsbl.sorbs.net refuses to say anything, oddly.)

RFC-Ignorant.Org does say, again, that Shaw itself is questionable.  So, does that mean all Shaw clients are silent tonight?  How big of a CIDR does this affect?  (And why?)  How come I’m the guy who gets picked on?

Once again, Shaw’s “help” “Support” line is of no use.  This time around “Jason” tells me I just have to be patient: the spam guys are looking into something.  He won’t venture any guesses as to what the something is.

A few days ago, I noted a very silly news story about someone getting hit with a computer virus. Well, maybe the administrators don’t know all that much about malware, and maybe a smaller local paper reporter didn’t know all that much about it, either.

But now the story has been taken up by a company that makes security software. A “Microsoft Gold Certified Partner,” according to their Website. A company that makes antivirus software. And their story is just as silly, or even worse.

They say the local admin “stated that, the virus is classified as harmful and they are being quite alert.” I suppose that is all well and good, but then they immediately say that, “[a]ccording to him, the anti-virus firms were not able to recognize it …” So, AV firms don’t know what it is, but it is classified as harmful? Oh, but not to worry, “the good part is that it doesn’t seem to do extensive harm.” So, it’s harmful, but it’s not harmful. Well, of course it’s not harmful. It only “collects information and details, such as bank accounts and passwords …” No possible problem there. (Oh, and, even though nobody knows what it is, it’s Qakbot.)

Right, then. Would you be willing to buy AV software from a firm that can make these kind of mistakes in a simple news story?

At the BC ISMS User Group meeting last week we were concentrating on the relationship between the ISO 27000 family of standards, and the PCI-DSS (Payment Card Industry Data Security Standards, usually just known as PCI).  PCI-DSS is of growing concern for pretty much anyone who does online retail commerce (and, come to that, anyone who does any kind of commerce that involves any use of a credit card).

It kind of crystalized some ideas that I’ve been mulling over recently.

Over the past year or so, I’ve been examining some situations for small charitable organizations, as well as some small businesses.  Many would like to sell subscriptions, raffle tickets, accept donations, or sell small, specialty items over the net.  However, I’ve had to consistently advise them that they do not want to get involved with PCI: it’s way too much work for a small company.  At the same time, most small Web hosting providers don’t want to get involved in that, either.

The unintended end result consequence of PCI is that small entities simply cannot afford to be involved with credit cards anymore.  (It’s kind of too bad that, a decade ago, MasterCard and Visa got within about a month of releasing SET [Secure Electronic Transactions] and then quit.  It probably would have been perfect for this situation.)

Somewhat ironically, PCI means a big boost in business for PayPal.  It’s fairly easy to get a PayPal account, and then PayPal can accept credit cards (and handle the PCI compliance), and then the small retailer can get paid through a PayPal account.  So far PayPal has not created anything like PCI for its users (which is, again, rather ironic given the much wilder environment in which it operates, and the enormous effort phishing spammers make in trying to access PayPal accounts.)  (The PayPal Website is long on assurances in terms of how PayPal secures information, and very short on details.)

This is not to say that credit cards are dead.  After all, most PayPal purchases will actually be made with credit cards: it’s just that PayPal will handle the actual credit card transaction.  Even radical new technologies for mobile payments tend to be nothing more that credit card chips embedded in something else.

These musings, though, did give a bit more urgency to an article on F-commerce: the fact that a lot of commercial and retail activity is starting to happen on Facebook.  Online retail transactions aren’t new.  They aren’t even new in terms of social networks or a type of currency created within an online system.  Online game systems have been dealing with the issue for some time, and blackhats have been stealing such credits and even using them to launder money for a number of years now.  However, the sheer size of Facebook (third largest “national population” in the world), and the fact that that entire population is (by selection) quite affluent means that the new Facebook credit currency may very quickly balloon to an enormous size in relation to other currencies.  (We will leave aside, for the moment, the fact that I personally consider Facebook to be tremendously divisive to the Internet as a whole.  And that Facebook does not have the best record in terms of security and privacy.)  Creation of wealth, ex nihilo, on a very, very large scale.  What are the implications of that?

I seem to be back on the air.

A few observations over this whole affair:

(Sorry, I’ve not had time to put these in particular order, and some of the point may duplicate or relate …)

1) I still have absolutely no idea why Shaw cut me off.  They keep blaming Spamhaus, but the only links they offer me as evidence clearly show that there is no “bad reputation” in the specific IP address that I am currently using, only a policy listing showing one of Shaw’s address ranges.

2) I got absolutely no warning from Shaw, and no notice after the fact.

3) Shaw’s spam filtering is for the birds.  Today I got two messages flagged as spam, for no clear reason I could see.  They were from a publisher, asking how to send me a book for review.  The only possible reason I could see was that the publisher copied three of my email addresses on the same message.  A lot of people do that, but it usually doesn’t trip the spam filter.  Today it did.  (Someone else with Shaw “service” tried to send out an announcement to a group.  Since he didn’t have a mailing list server, he just sent out a bunch of messages.  Apparently that got *his* account flagged as spamming.)  I also got the usually round of messages from security mailing lists tagged as spam: Shaw sure has something against security.  And at least one 419 scam got through unflagged today, despite being like just about every other 419 in the world.  (Oddly, during this period I’ve noted a slight uptick in 419s and phishing in general.)

4) Through this episode I had contact with Shaw via email, phone, “live chat,” and Twitter.  I follow ShawInfo and Shawhelp on Twitter.  On Twitter, I was told to send them a direct message (DM).  I had, in fact, tried to do that, but Shaw doesn’t accept direct messages by default.  (Since I pointed that out to them, they now, apparently accept them from me.)  They sent me public messages on Twitter, and I replied in kind.  Through the Twitter account they also informed me that error 554 is “poor reputation” and is caused by sending too many emails.  They didn’t say how many is too many.  (Testing by someone else indicated something on the order of 50-100 per hour, and I’ve never done anything near that scale.)

5) The “live chat” function installs some software on your (the client) machine.  At least two of the pieces of software failed the digital signature verification …

6) The “information” I got from Shaw was limited.  The first (phone) support call directed me to http://www.senderbase.org/senderbase_queries/detailip?search_string=70.79.166.169  If you read the page, the information is almost entirely about the “network” with only a few (and not informative) pieces about the IP address itself.  (I did, separately, confirm that this was my IP address.)  The bulk of the page is a report on addresses that aren’t even in the same range as I am.  About halfway down the right hand side of the page is “DNS-based blocklists.”  If you click the “[Show/Hide all]” link you’ll notice that four out of five think I’m OK.  If you click on the remaining one, you go to http://www.spamhaus.org/query/bl?ip=70.79.166.169  At the moment, it shows that I’m completely OK.  At the time I was dealing with Shaw, it showed that it’s not in the SpamHaus Block List (SBL) or the XBL.  It was in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

7) The second (live chat) support call sent me to http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+  Again, this page showed a single negative entry, and a whole page of positive reports.  The single negative entry, if pursued, went to the same Spamhaus report as detailed above.

8) At the time, both initial pages, if followed through in terms of details, led to http://www.spamhaus.org/pbl/query/PBL164253 giving, as the reason, that “This IP range has been identified by Spamhaus as not meeting our policy for IPs permitted to deliver unauthenticated ‘direct-to-mx’ email to PBL users.”  Again, Shaw’s problem, not mine.  However, that page has a link to allow you to try and have an address removed.  However, it says that the “Removal Procedure” is only to be used “If you are not using normal email software but instead are running a mail server and you are the owner of a Static IP address in the range 70.79.164.0/22 and you have a legitimate reason for operating a mail server on this IP, you can automatically remove (suppress) your static IP address from the PBL database.”  Nevertheless, I did explore the link on that page, which led to http://www.spamhaus.org/pbl/removal/  Again, there you are told “You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server, and (B) if you have a specific technical reason for needing to run a ‘direct-to-MX’ email service, such as a mail server appliance, off the Static IP address. In all other cases you should NOT remove an IP address from the PBL.”  This did not refer to my situation.  Unfortunately, THESE TWO PAGES ARE INCORRECT.  If you do proceed beyond that page, you get to http://www.spamhaus.org/pbl/removal/form  This page does allow you to submit a removal request for a dynamic IP address, and, in fact, defaults to dynamic in the form.  It was only on the last part of the second call, when the Shaw tech gave me this specific address, that I found this out.  For this I really have to blame Spamhaus.

9) In trying to determine if, by some weird mischance, my computer had become infected, I used two AV scanners, one spyware scanner, and two rootkit scanners.  (All results negative, although the Sophos rootkit scanner could have been a bit clearer about what it had “found.”)  Of course, I’ve been in the field for over two decades.  How would the average user (or even a security professional in a non-malware field) even know that there are different types of scanners?  (Let alone the non-signature based tools.)

BKEXTDET.RVW   20101023

“Extrusion Detection”, Richard Bejtlich, 2006, 0-321-34996-2,
U$49.99/C$69.99
%A   Richard Bejtlich www.taosecurity.com taosecurity.blogspot.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-34996-2
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/0321349962/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321349962/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321349962/robsladesin03-20
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   385 p.
%T   “Extrusion Detection:Security Monitoring for Internal Intrusions”

According to the preface, this book explains the use of extrusion detection (related to egress scanning), to detect intruders who are using client-side attacks to enter or work within your network.   The audience is intended to be architects, engineers, analysts, operators and managers with an intermediate to advanced knowledge of network security.  Background for readers should include knowledge of scripting, network attack tools and controls, basic system administration, TCP/IP, as well as management and policy.  (It should also be understood that those who will get the most out of the text should know not only the concepts of TCP/IP, but advanced level details of packet and log structures.)  Bejtlich notes that he is not explicitly addressing malware or phishing, and provides references for those areas.  (It appears that the work is not directed at information which might detect insider attacks.)

Part one is about detecting and controlling intrusions.  Chapter one reviews network security monitoring, with a basic introduction to security (brief but clear), and then gives an overview of monitoring and listing of some tools.  Defensible network architecture, in chapter two, provides lucid explanations of the basics, but the later sections delve deeply into packets, scripts and configurations.  Managers will understand the fundmental points being made, but pages of the material will be impenetrable unless you have serious hands-on experience with traffic analysis.  Extrusion detection itself is illustrated with intelligible concepts and examples (and a useful survey of the literature) in chapter three.   Chapter four examines both hardware and software instruments for viewing enterprise network traffic.  Useful but limited instances of layer three network access controls are reviewed in chapter five.

Part two addresses network security operations.  Chapter six delves into traffic threat assessment, and, oddly, at this point explains the details of logs, packets, and sessions clearly and in more detail.   A decent outline of the advance planning and basic concepts necessary for network incident response is detailed in chapter seven (although the material is generic and has limited relation to the rest of the content of the book).  Network forensics gets an excellent overview in chapter eight: not just technical points, but stressing the importance of documentation and transparent procedures.

Part three turns to internal intrusions.  Chapter nine is a case study of a traffic threat assessment.  It is, somewhat of necessity, dependent upon detailed examination of logs, but the material demands an advanced background in packet analysis.  The (somewhat outdated) use of IRC channels in botnet command and control is reviewed in chapter ten.

Bejtlich’s prose is clear, informative, and even has touches of humour.  The content is well-organized.  (There is a tendency to use idiosyncratic acronyms, sometimes before they’ve been expanded or defined.)  This work is demanding, particularly for those still at the intermediate level, but does examine an area of security which does not get sufficient attention.

copyright, Robert M. Slade   2010     BKEXTDET.RVW   20101023

BKCOCISW.RVW   20101229

“Codes, Ciphers and Secret Writing”, Martin Gardner, 1972,
0-486-24761-9, U$4.95/C$7.50
%A   Martin Gardner
%C   31 East 2nd St., Mineola, NY  11501
%D   1972
%G   0-486-24761-9
%I   Dover Publications
%O   U$4.95/C$7.50 www.DoverPublications.com
%O  http://www.amazon.com/exec/obidos/ASIN/0486247619/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0486247619/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0486247619/robsladesin03-20
%O   Audience n- Tech 1 Writing 2 (see revfaq.htm for explanation)
%P   96 p.
%T   “Codes, Ciphers and Secret Writing”

This brief pamphlet outlines some of the simple permutation and substitution ciphers that have been used over time.  The emphasis is on the clever little tricks that go into making ciphers slightly harder to crack.  None of the algorithms are terribly sophisticated, and exercises are given at the end of each chapter.  Instructions are given for decrypting some of the ciphers, even if you don’t know the key.

Two additional chapters address related topics.  The first deals with various forms of secret writing, such as invisible inks, or steganographic messages.  The last chapter briefly examines the problem of creating messages that unknown people, with unknown languages, may be able to solve (such as sending messages to the stars).

None of the material is strenuous, but this may be a nice start before moving on to a work such as Gaines “Cryptanalysis” (cf. BKCRPTAN.RVW).

copyright, Robert M. Slade   2010     BKCOCISW.RVW   20101229

Crazy busy, this time of year, isn’t it?  That’s why I haven’t gotten back to this until now.

(Mind you, last Sunday, at church, the kids put on this play, the point of which was that the “busy” parts of Christmas often aren’t the most important aspects.  The tagline to the play was that you should be busy about the right things, not the wrong ones.  And we’ve mostly been busy with the twins.

For example, #2 Daughter was heavily involved in the local Atom hockey tournament, since #3 Grandson was in one of the teams.  So, we pulled extra babysitting time while she had to be running things, and he *didn’t* have to be there.

The famous Coquitlam Atom Boom Boom Puck Jam Hockey tournament was won, Tuesday, by the Coquitlam Chiefs C1 team in an exciting finish.  Tied after regulation time [with full 15 minute periods, rather than the normal Atom 12, with the third period shortened if anything in the game goes overtime], and still tied after five minutes of 4 on 4 sudden death overtime, the final was won in the second-to-last shot of a shoot-out.

Because of conflicting appointments, Grandpa (of #6, right wing forward) had to travel an hour and a half, taking the Skytrain and bus out to the rink, but is still chuffed 

But the disappointments, of which I speak, had to do with computers.  Part of the pain of buying new stuff, is that things you thought you could rely on, well, it turns out you can’t, anymore.

One of them is NOD32.  Eset does make a good product, although it tends to be fairly greedy for cycles, while operating, and a bit arrogant in terms of what it tells you.  So, when a family member was in trouble over an infection (always embarrassing when your own family doesn’t take precautions, isn’t it?) I had no hesitation in applying NOD32 to try and clean it up.  Well, the machine is older, and slow.  And, hasn’t been updated in a while, so I was trying to fix that, too.  NOD32, even after finishing it’s scan, was interfering with the update process.  So much so, that it got to the point where we thought the machine was unrecoverable.

We did get it back in operation.  (And, first thing, removed NOD32.)  But it’s disappointing when a trusted tool bites you.

(Speaking of the which, I’ve spoken before about MSE, and even mentioned some of the performance degradation it can cause in older machines.  I must say, that, in some recent experiences, I’m more and more impressed with it as a means of rescuing computers that have been infected.)

More closely related to the new computers, one of my favourite places to get computer equipment, over the years, has been a western Canadian drugstore chain called London Drugs, similar (for those of you in the States) to Walgreens, although sometimes London Drugs is closer in scale to Target.  For twenty years I have been sending people to them for good advice, knowledgable staff, and decent prices.

Well, one of the computers I bought, this time around, is a Mac.  I’m not familiar with Macs, so I was relying on their advice.  Actually, the advice that I got from one staffer was quite good.  But, when I went to actually buy the machine, I got it home and found that what I had brought home was not what I’d ordered.  Which reminded me that the last time I needed to get a printer cartridge, again, they gave me the wrong one.  (There is also that fact that, in relying on their advice over what I needed, they sold me some completely unnecessary software, when the function I wanted is already built in to the Mac.)
Overall, I think they still are a reasonably decent place to get stuff, but, obviously, they may be victims of their own success.  Getting a bit careless, perhaps.  So, equally obviously, I can’t just rely on them any more, and will have to be careful about who I send there, as well.
Like I  said, a bit of a disappointment …

BKDRJNDL.RVW   20091129

“The Design of Rijndael”, Joan Daemen/Vincent Rijmen, 2002, 3-540-42580-2
%A   Joan Daemen
%A   Vincent Rijmen
%C   233 Spring St., New York, NY   10013
%D   2002
%G   3-540-42580-2
%I   Springer-Verlag
%O   212-460-1500 800-777-4643 service-ny@springer-sbm.com
%O  http://www.amazon.com/exec/obidos/ASIN/3540425802/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/3540425802/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/3540425802/robsladesin03-20
%O   Audience s- Tech 3 Writing 1 (see revfaq.htm for explanation)
%P   238 p.
%T   “The Design of Rijndael: AES - The Advanced Encryption Standard”

This book, written by the authors of the Rijndael encryption algorithm, (the engine underlying the Advanced Encryption Standard) explains how Rijndael works, discusses some implementation factors, and presents the approach to its design.  Daemen and Rijmen note the linear and differential cryptanalytic attacks to which DES (the Data Encryption Standard) was subject, the design strategy that resulted from their analysis, the possibilities of reduce round attacks, and the details of related ciphers.

Chapter one is a history of the AES assessment and decision process.  It is interesting to note the requirements specified, particularly the fact that AES was intended to protect “sensitive but unclassified” material.  Background in regard to mathematical and block cipher concepts is given in chapter two.  The specifications of Rijndael sub-functions and rounds are detailed in chapter three.  Chapter four notes implementation considerations in small platforms and dedicated hardware.  The design philosophy underlying the work is outlined in chapter five: much of it concentrates on simplicity and symmetry.
Differential and linear cryptanalysis mounted against DES is examined in chapter six.  Chapter seven reviews the use of correlation matrices in cryptanalysis.  If differences between pairs of plaintext can be calculated as they propagate through the boolean functions used for intermediate and resultant ciphertext, then chapter eight shows how this can be used as the basis of differential cryptanalysis.  Using the concepts from these two chapters, chapter nine examines how the wide trail design diffuses cipher operations and data to prevent strong linear correlations or differential propagation.  There is also formal proof of Rijndael’s resistant construction.  Chapter ten looks at a number of cryptanalytic attacks and problems (including the infamous weak and semi-weak keys of DES) and notes the protections provided in the design of Rijndael.  Cryptographic algorithms that made a contribution to, or are descended from, Rijndael are described in chapter eleven.

This book is intended for serious students of cryptographic algorithm design: it is highly demanding text, and requires a background in the formal study of number theory and logic.  Given that, it does provide some fascinating examination of both the advanced cryptanalytic attacks, and the design of algorithms to resist them.

copyright Robert M. Slade, 2009    BKDRJNDL.RVW   20091129

Sunday 11th July saw the release of the latest version of the Metasploit Framework, and you can tell that the guys have been really busy over in Metasploit development land. Please see the release notes for this version below, and you can download the latest version from here.

Statistics

• Metasploit now has 567 exploits and 283 auxiliary modules (up from 551 and 261 in v3.4)
• Over 40 community reported bugs were fixed and numerous interfaces were improved

General

• The Windows installer now ships with a working Postgres connector
• New session notifications now always print a timestamp regardless of the TimestampOutput setting
• Addition of the auxiliary/scanner/discovery/udp_probe module, which works through Meterpreter pivoting
• HTTP client library is now more reliable when dealing with broken/embedded web servers
• Improvements to the database import code, covering NeXpose, Nessus, Qualys, and Metasploit Express
• The msfconsole “connect” command can now speak UDP (specify the -u flag)
• Nearly all exploit modules now have a DisclosureDate field
• HTTP fingerprinting routines added to some exploit modules
• The psexec module can now run native x64 payloads on x64 based Windows systems
• A development style guide has been added in the HACKING file in the SVN root
• FTP authentication bruteforce modules added

Payloads

• Some Meterpreter scripts (notably persistence and getgui) now create a resource file to undo the changes made to the target system.
• Meterpreter scripts that create logs and download files now save their data in the ~.msf3/logs/scripts folder.
• New Meterpreter Scripts:

• enum_firefox - Enumerates Firefox data like history, bookmarks, form history, typed URLs, cookies and downloads databases.
• arp_scanner - Script for performing ARP scan for a given CIDR.
• enum_vmware - Enumerates VMware producst and their configuration.
• enum_powershell - Enumerates powershell version, execution policy, profile and installed modules.
• enum_putty - Enumerates recent and saved connections.
• get_filezilla_creds - Enumerates recent and saved connections and extracts saved credentials.
• enum_logged_on_users - Enumerate past users that logged in to the system and current connected users.
• get_env - Extracts all user and system environment variables.
• get_application_lits - Enumerates installed applications and their version.
• autoroute - Sets a route from within a Meterpreter session without the need to background the sessions.
• panda_2007_pavsrv53 - Panda 2007 privilege escalation exploit.

• Support for a dns bypass list added to auxiliary/server/fakedns. It allows the user to specify which domains to resolve externally while returning forged records for everything else. Thanks to Rudy Ruiz for the patch.
• Railgun - The Meterpreter “RAILGUN” extension by Patrick HVE has merged and is now available for scripts.
• PHP Meterpreter - A protocol-compatible port of the original Meterpreter payload to PHP. This new payload adds the ability to pivot through webservers regardless of the native operating system
• Token impersonation now works with “execute -t” to spawn new commands with a stolen token.

Known Issues

• Interacting with a meterpreter session during a migration will break the session. See #1360.
• There is no simple way to interrupt a background script started by AutoRunScript
• Command interaction on Windows causes a PHP Meterpreter session to die. See #2232