My review on “Algorithms on strings”

My review on “Algorithms on strings” (for which I’ve blogged before) for the ACM SIGACT News is out. There’s a typographical error though: I did not review “Algorithms on strings” by Dan Gusfield, but “Algorithms on strings” by Crochemore, Hancart and Lecroq.

Thank you Bill Gasarch for the opportunity and thank you for fixing the typo too!

PS: You can download the review PDF from Bill Gasarch’s site.

Update: The review entry is corrected in the ACM site: Like Bill Gasarch wrote to me: “There is no such thing as a final version of anything anymore!

What goes around comes around

Reading “A co-Relational Model of Data for Large Shared Data Banks” (a title inspired by Codd‘s “A Relational Model of Data for Large Shared Data Banks“) reminded me of M. Stonebraker’s and J. Hellerstein’s “What goes around comes around” which is one of the coolest papers one can read if one wants to know how life was before the Relational Model (that is before SQL for those who do not love theory). It is also a cool reading for the NoSQL crowd because while you might think this is all new, it’s actually a bit of a return to the past.

It seems that this co-relational model tries to answer my favorite question directed to NoSQLers: “Where is the math?” It does so by using category theory. However:

“Obviously, the precise formalization of SQL and noSQL as categories is outside the scope of this article”

Although my category-fu is non-existent I could not help not remembering Pauli‘s response to Heisenberg’s claims that they (Pauli and Heisenberg) had found a unified theory but the technical details were missing:

This is to show the world that I can paint like Titian.

Pauli's Titian

Only technical details are missing

It will be really nice if this duality is formally proven for I had a hunch that a relationship existed, only I could not really determine it.

[Pauli’s painting from here]

Cyberdefense and the Kobayashi Maru

This is the title of the presentation that I gave yesterday at the Greek OWASP Chapter meeting which was held at the CoLab. The presentation is based on my experiences in participating in three Cyberdefense exercises and can basically be summarized by the following points:

  • Cyberdefense exercises are not a competition. We do not participate to “win”. In fact if there’s any win-lose objective it is a success that we lose. From loss we can learn; a lot.
  • Given that there are no actual attacks taking place during the exercises, communication is what we exercise on.
  • Cyberdefense exercises are about team formation. Team formation of organizations and individuals who up to now were not particularly interested in cooperating, since besides being critical infrastructures no other common ground exists between them.
  • According to Tuckman, group development has four stages: forming, storming, norming and performing.
  • Due to the fact that with each exercise the number of participants increases, we iterate a lot between forming and storming.
  • Parkinson’s Law emerges a lot during storming. Cyberdefense is an enormous complex beast, difficult to grasp, but there exist in it tiny bits for everyone to understand well enough to consider them most important (even from the whole picture).
  • Building a web of trust among people is the key to everything. Cyberdefense exercises help in developing trust because they bring people together.
  • While organizing Cyberdefense (and understanding Cyberoffense) the following model from Best and Luckenbill must be in our minds:
    Form of Organization Mutual Association Mutual Participation Division of Labor Extended Organization
    Loners no no no no
    Colleagues yes no no no
    Peers yes yes no no
    Mobs yes yes yes no
    Formal Organizations yes yes yes yes

Many thanks to @kpapapan for inviting me to give the talk and to the audience for bearing with my rants.

A simple incident taxonomy

Yesterday I learned about the International Nuclear Event Scale. Given this tool nuclear accidents are characterized in a 7 degree scale as follows:

  • 7 – Major Accident
  • 6 – Serious Accident
  • 5 – Accident with Wider Consequences
  • 4 – Accident with Local Conswquences
  • 3 – Serious Incident
  • 2 – Incident
  • 1 – Anomaly
  • 0 – Deviation (No safety significance)

Uppon seeing the scale I thought that it could be useful for characterizing cyber incidents too. Yeah I know, like we do not already have enough incident taxonomies. But I like it anyway.

mail hosted at Google, web server elsewhere

This post aims to cover two sets of questions that frequently appear on Serverfault:

“I have the email of my organization hosted at Google and the web server at a hosting provider. When the web server sends email (when a form is completed for example), email is received by everyone except when the recipient is in our domain. Then sendmail tries to deliver locally and not over at Google”. Or, “certain recipients, including Google, reject email from the web server (or servers withing our LAN) as spam”.

There are answers at Serverfault recommending the use of ssmtp in order to forward all sending email via Google, but this requires SMTP authentication and a password saved in a file.

For the purposes of this post the domain example.com will be used.

Configure SPF for example.com

SPF is framework that allows the domain name owners notify the world who they believe the appropriate servers sending mail on behalf of their domain are. Google support pages note that the SPF record should at least be in the form of v=spf1 include:_spf.google.com ~all. However, it is also needed that server.example.org be able to send email on behalf of example.com. So the appropriate record becomes:

v=spf1 a:server.example.org include:_spf.google.com ~all

Note: example.org is not the same domain as example.com

Configure sendmail for server.example.org

example.com is included in /etc/mail/local-host-names, which means that server.example.org treats this a local domain and will try to deliver locally, instead of Google. The following additions to the sendmail configuration file (sendmail.mc) take care of this:

LOCAL_CONFIG
Kbestmx bestmx -T.TMP

LOCAL_RULE_0
R $* < @ example.com. > $*
    $#esmtp $@ [$(bestmx example.com. $)] $: $1 < @ example.com. > $2

The line is broken in two for readability. As always remember that the LHS and the RHS of the rule are separated with tabs and not spaces. So do not copy-paste. Build and install sendmail.cf, restart sendmail and check.

I would welcome additions on how the same can be achieved with postfix or exim.

The story of Server 54

I’m sure I’ve blogged about this before, but I cannot find it right now. Anyway the following tweet:

Beaker RT @etherealmind: Existential Angst 4 Network Engineers: If a Network Device isn’t Monitored, does it really exist? < Does when it goes down

brought to my attention by @DrInfoSec triggered my memory to recall the story of Server 54. A story that I reproduce here thanks to the Internet Archive:

The University of North Carolina has finally found a network server that, although missing for four years, hasn’t missed a packet in all that time. Try as they might, university administrators couldn’t find the server. Working with Novell Inc. (stock: NOVL), IT workers tracked it down by meticulously following cable until they literally ran into a wall. The server had been mistakenly sealed behind drywall by maintenance workers.

Digging a little bit more, one can find a few more discussions on Server 54.