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.
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.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
| Android's Limits | Jun 04, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Linux Systems Administrator
- Introduction to MapReduce with Hadoop on Linux
- Senior Perl Developer
- Technical Support Rep
- Weechat, Irssi's Little Brother
- UX Designer
- One Tail Just Isn't Enough
- Android's Limits
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?




12 min 46 sec ago
1 hour 42 sec ago
1 hour 1 min ago
3 hours 26 min ago
7 hours 36 min ago
7 hours 40 min ago
1 day 3 hours ago
1 day 4 hours ago
1 day 4 hours ago
1 day 7 hours ago