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.
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.
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.
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.
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:
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:
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 telephone, Bell’s most ambitious gadget yet, reached this stage on March 10, 1876. On that great day, Alexander Graham Bell became the first person to transmit intelligible human speech electrically. As it happened, young Professor Bell, industriously tinkering in his Boston lab, had spattered his trousers with acid. His assistant, Mr. Watson, heard his cry for help—over Bell’s experimental audio-telegraph. This was an event without precedent.”