Security Begins with Me
I recently stopped by the Seattle offices of the security consulting firm @stake (the current employer of world-famous Mudge) to have lunch with Frank Heidt, a friend who is managing security architect. I unexpectedly ended up having to wait some minutes while Frank attended a conference call. When he came out, it was to complain about the weekend of work ahead and to tell me that our lunch would have to be a ten-minute coffee break instead.
The conference call had been from a client company who was having difficulty in selecting among the short list of unsavory options presented by @stake. They are the victims of their own security department gone rogue. At this point, at the mercy of their own employees, their choices are few and expensive. Frank tells me that in his experience, a significant majority of security cracks and threats are internal, which reminded me that a majority of murders and rapes are also committed by perpetrators known to the victim. Rather than barred windows, pepper spray and firewalls, the better investment may be in the time you take to choose whom you let in the physical door. As Bob Toxen writes in Real World Linux Security, “The presence of a firewall...should not be an excuse to allow insecure systems behind it.”
Given that complete security is unachievable and laxity foolhardy, I asked Frank about his security philosophy. He replied that he doesn't really have one specifically, but that the client's requirements should determine the security strategy to be taken. He views security not as a magic list of firewalls, tools and daily tasks (though he believes Snort to be about the best IDS out there) but more of a set of requirements to be met and limitations to be considered. For those looking for that holy grail of security, this seems like a nonanswer, but it's really the only one that makes sense. Apologies for returning to physical-safety metaphors, but it's just too similar to what a self-defense instructor friend of mine used to tell me. He couldn't provide specific actions for a given attack, such as “When he grabs your arm kick him in the groin” (a rather ineffectual way of deterring a determined attacker incidentally), because attacks aren't scripted. Defense needs to be based on principles, such as “against a stronger attacker, your safest position is in close”, rather than given techniques.
In both situations the most important work is up to the company or person seeking security and defense. A secure system is the result of an intimate knowledge of individual security requirements and limitations. Consultants are valuable for providing technical know-how and pointing out possibilities, but your network security is ultimately work that must be done by you.
Rob Beck's (another @staker) article in this month's feature section is a good example. He provides a great little application for fingerprint evasion, but the level of anonymity (and even whether anonymity is high on one's security priority list) is up to the user, as Rob points out.
In addition to the usual Paranoid Penguin and security feature articles, this issue's Kernel Korner, Focus on Software and Take Command are also secure-centric. In fact, we ended up with so many HOWTO security articles that a number of them couldn't be squeezed into the print magazine and were relegated to the infinite space of our web site—see the Strictly On-Line section of the contents page for titles.
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Huge Package Overhaul for Debian and Ubuntu
- Shashlik - a Tasty New Android Simulator
- KDE Reveals Plasma Mobile
- Embed Linux in Monitoring and Control Systems
- diff -u: What's New in Kernel Development