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.
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- Dynamic DNS—an Object Lesson in Problem Solving
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Roll your own dynamic dns
4 hours 6 min ago
- Please correct the URL for Salt Stack's web site
7 hours 18 min ago
- Android is Linux -- why no better inter-operation
9 hours 33 min ago
- Connecting Android device to desktop Linux via USB
10 hours 1 min ago
- Find new cell phone and tablet pc
11 hours 4 sec ago
12 hours 28 min ago
- Automatically updating Guest Additions
13 hours 37 min ago
- I like your topic on android
14 hours 23 min ago
- This is the easiest tutorial
20 hours 59 min ago
- Ahh, the Koolaid.
1 day 2 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?