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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
- Rogue Wave Software's Zend Server