noc8.jpg
.: September 2007 Archives
August 2007 | October 2007


.: powershell: removing items from an array
I've been working again with PowerShell, doing some new things. There are still a few nuances to a newbie like me. For instance, while it is easy to create arrays, it is a bit more arcane to remove items from an array. Thankfully, I found a site that gave me the answers I need.

To remove the first item in an array, reassign only items 1 through the length of the array back into the array (or a new array). Remember that arrays are indexed with the first item as 0, not 1.
$array = $array[1..$array.Length]
.: powershell nuance with appendchild to an empty parent
I have adopted the use of xml files as configuration files for any PowerShell scripts I've been writing for work lately. Today I just found an odd bit of behavior when working with building a new xml file (if the script runs and sees no existing xml config file, it creates one). Normally, adding child objects in xml is fairly straightforward. Assume this is the existing xml.
<installcontrol>
   <serverlist>
      <server>
         <servername>ALDARAAN</servername>
         <servername>TATOOINE</servername>
      </server>
   </serverlist>
<installcontrol>
We can use this script to add a new child server, DANTOOINE.
$xmlFile = Get-Content $xpath
$objNewServer = $xmlFile.CreateElement("server")
$objNewServerName = $xmlFile.CreateElement("servername")
$objNewServerName.Set_InnerText("DANTOOINE")
$objNewServer.AppendChild($objNewServerName)
$xmlFile.installcontrol.serverlist.appendchild($objNewServer)
$xmlFile.Save("$xpath")
This is great, but what if there are no child objects already present, such as in this xml file.
<installcontrol>
   <serverlist>
      <server>
      </server>
    </serverlist>
<installcontrol>
Powershell complains that it can't add append a child to a string. The script needs to change slightly to accomodate. The following snippet will work both for empty parents and also populated parents. The difference is in the 6th line.
$xmlFile = Get-Content $xpath
$objNewServer = $xmlFile.CreateElement("server")
$objNewServerName = $xmlFile.CreateElement("servername")
$objNewServerName.Set_InnerText("DANTOOINE")
$objNewServer.AppendChild($objNewServerName)
$xmlFile.installcontrol["serverlist"].appendchild($objNewServer)
$xmlFile.Save("$xpath")
.: the practice of system and network administration
Upon recommendation in the Security Catalyst Forums, I picked up a copy of The Practice of System and Network Adminsitration by Thomas Limoncelli, et al.

So far I am impressed by the book. This is an ideal book to give any manager or beginner/intermediate SA/NA. It stays technical, but so far all of the advice is very general and common sense for any IT shop. Do automation, do this, don't do this, this is why this is a bad idea, these are universal steps to get yourself out of the hole...

There are moments of mangled sentences and some of the topics seem a bit dated (Windows NT...) but this is so far a book I think I'd like to see on the shelf of any manager (or SA team library) I might have for the foreseeable future. It may not tell you how to automate deployments of Windows XP workstations, for example, but it will give you the reasons why this is a good idea and approaches to take to get shit done.

It is also nice to see some things I've learned on my own to be echoed in this book, validating my own common sense and reinforcing confidence. Despite being a big book (over 1000 pages), it can be read in chunks and is an easy read nonetheless.
.: survival of the fittest...or the most economical
Ahh, summer's beginning to give up her fight [1], portending my favorite season, Autumn! I've also been busy at work and at play, which has limited my posting energy. Not only that, but holy crap have some of my feeds been posting a ton the past couple weeks! It is tiring trying to keep up with them, or even to scroll through the articles I don't care to read.

Today's news comes from Marcin who reviews the question of going with a series of best of breed solutions or all-in-one security packages? You'll almost certainly have cost and support benefits from an all-in-one solution, but it may still have small gaps, and certainly tends to be weaker in some areas, if not weaker than the whole of a series of best of breeds put together.

What I would choose is as good in the best of breed as I can afford in time and money based on my company size. As a techie, I'd much prefer best of breed over all-in-one behemoths. I tend to find best of breeds to be more trustworthy and much more surgical in their approaches. In a way, that illustrates a comparison. Would you prefer a specialized surgeon to perform operation X, or a more commoditized but affordable provider? What about for a routine operation? Do you want a common product or something specialized? Agility?

Compliance promotes this idea as does the maturing of the security industry, but should we really settle for "Good Enough" security? Perhaps that is pragmatic, but I'd still like to think anything I secure is better than the typical Good Enough...

[1] If you know this song, props to you, you have some taste!
.: picking more locks
I've previously mentioned that I'm getting into lockpicking, and I continue to practice in small pieces of spare time. Last week I picked my first non-practice lock, a 5-pin dead bolt in my apartment. Just tonight I sat down to try it again and picked it three times in 6 minutes. I'm a little scared, but happy with my progress!

I've been able to start to actually feel the various "gives" when a pin is set, as well as the sounds. Sometimes there is a small give in the torque when a pin clears. Sometimes a small click. Sometimes it is the lack of tactile response from the pin when it is set and the spring no longer pushes down on the pick. All of these evidences are getting more and more common. I'm even surprised more and more at how easy raking a lock open can be. Raking involves moving a jagged rake pick in and out of the key way such that several pins quickly set, as opposed to picking the pins one by one. Insert torque, slide in a rake pick, and before I've even completed two "rakes" the lock is open. I've done that a few times much to my surprise. If you know what a bumping is, raking is smack in the middle of the spectrum between bumping and pin-by-pin picking.

Sunday evening I watched War in the theater and for the first third of the movie and through the previews had a lock and pick in my hands just opening it over and over, while not trying to create a pattern of it. I don't want to unlock my locks just because I follow the same pattern each time, but rather to open them through actual semi-conscious effort.

So far it has been working, and is quite a nice little idle activity. I might move up to my cut out spool pin lock this week. You can see a picture of a spool pin towards the bottom of this really interesting page on lockpicking. This page looks like something nice to read. I especially enjoyed skimming down to the part about unset/unbinding pins and the various states, plus how they feel so as to identify the state.
.: the ghosts of digital crime
The Register posted an article about Max Butler being busted again by authorities. Two things about this article.

1) As if we don't need more awareness of wireless insecurity...oh wait, obviously we do. Max would go to hotels and intercept wireless communications. Hello there, ripe opportunities!

2) In the bootnote, I see, "Some kids think they can't get into trouble for hacking computer systems..." Now, let's look at crime in general, let alone digital crime. I'd be willing to say that people are not so much caught breaking into something as they are caught bragging about it or trying to sell any goods they stole from said breaking or hacking. If I intercept and break into your wireless network from a hotel room, unless I'm stupid and visited my gmail account on your network, you likely aren't going to have anything on me. If I steal your wallet, I'm a ghost. Until I show up at the grocery store and attempt to use that credit card or cash that paycheck you received....

However, I would say an exception would be when you discover a break-in while it is in progress. A guard seeing someone climb a fence could stop a theft and arrest the intruder. The same might be said about a digital break-in, possibly. But still, a breakin where I actually get away means I'm a ghost.

I want to brainstorm a moment. The steps of a theft?

a) Someone decides to commit a crime. Often, crime occurs in a moment of opportunity or desparation. I don't plan to steal someone's wallet, but when I see it just lying there, or that accountant computer sitting unlocked... Or I can't pay my bills and absolutely need money or go homeless... Otherwise, commiting a crime typically means overcoming some internal moral compass and disregarding external moral judgements. Many people don't run red lights because that's Just Bad or because other people are watching. Same with many crimes. They don't occur because they are Just Bad. Which is why the first time is the hardest, and repeating offenses are so important to watch. Other than maintaining cultural morals, you can't do much about this. The digital age has largely removed the "people are watching" barrier (the external moral judgements), especially on the Internet. Just ask any child predator.

b) Someone is breaking in. You have a great chance to catch someone here, or thwart their attempts. Guards, alarms, dilligence, logging, monitoring, razorwire, locks.

c) Someone has broken in and left. This is the ghost stage. Unless they left behind some solid evidence, they're a ghost. Take inventory and try to determine motive or start cleaning up.

d) Profiting from the crime. This is the next chance to really catch someone when they attempt to sell the goods or do something with their ill-gotten gains. Whether it is bragging or selling credit cards, this is the next tripwire where you can catch someone. Of course, if the goods are not trackable, such as common cash, then you're still out of luck. If I steal your wallet, grab the cash, then burn the rest, you're still out of luck when I buy some 40s with the cash.
.: the religious ugly of browser choices
In the workplace, I tend to avoid a the common conversations: money, religion, politics, and even sex. These things tend to be wedges between people. People get way too fanatic about some of them, or it becomes a decisive topic. I'm careful with whom I open up to about those things, and where and when.

Today I clicked to visit a blog site I have in my RSS reader. I clicked through from work and up popped a flat out denial screen because I was using IE as my browser. Now, we make people use IE, but some of us do get to use Firefox when we test or need something new, however I don't make myself a complete standing exception by using IE almost all of the time like every other user. And no, this wasn't just a warning page that let me into the site, but rather a complete, 100% denial of entry.

Seriously, take your browser and OS religion and put it elsewhere. I don't subscribe to political or religious blogs. And while I sometimes read that particular offending blog, I decided it is not worth giving the author another feed hit, so I unsubscribed.

I don't mind people saying Firefox is better, or reminding me that I'm on IE through a splash page. In fact, given the option, I'd use Firefox over IE anyway, which I do at home (and with a blank user-agent). But discriminating users with full denial based on browser choice is ridiculous.
.: reality check from the fark attack
It is not breaking news that fark.com was the victim/target of a hacking attack. But take a moment to think about this attack. Someone sent spam and spoofed emails to Fark employees. The spoofed emails appeared to be from colleagues. The links contained went to websites hosting trojans and other malware, some of which seems to have stolen and sent out pilfered passwords.

Think about how your organization would be protected from an attack like this.

Users don't check email headers, at all. They wouldn't know these messages are spoofed unless there is something obviously wrong or they yell over the cube wall to ask. Should the users even see these emails?

If one user accidentally clicks the link, will their browser be susceptible? Their OS? Their administrative/user level on the system?

Would they know something happened and say something? What if they don't, can you run a history search to see who in your company visited those bad sites?

Will the OS scream bloody hell if a trojan is found? If a trojan is detected by AV but no analysts are around to check the logs, does it do damage?

There's a lot of breakdowns here that I would not be the least surprised are breakdowns in 95% of companies. And guess what...I bet Fark isn't a Fortune 500 and not a huge employer, and they were still the victim of a targeted attack. And no, I don't think user education is a guarantee of protection.

As a side note, I think user education is valuable, but I also think it has some dangers. It shouldn't be used to reassign blame, for instance to some user who clicked on a link when they should have known better from their training. That's not productive punishment or assignment of accountability or blame. Likewise, can you detect when they break down? If not, why bother training? If so, then likely you have the technological means to compensate for less user training. I'm not anti-user training, but I am against viewing at as more than an augment to a company's security posture and culture.
.: technitium mac changer updated
The free Windows MAC-changer tool, Technitium MAC Address Changer has had a new release. Yeah, so what, it's easy to change a registry key, but we all know that once you know the how and why, you want to do things easy and quick, hence tools like this that automate the mundane. This tool should be up there just under the ranks of Cain and NMap as necessary free tools for Windows.
.: calling a powershell script from a powershell script
Doing things in PowerShell is often simple, but finding them out for the first time is sometimes not. This little tidbit took a good half hour of my day. I wanted to call another script from my first script. I didn't mind if I needed to wait for execution to finish before moving on, and I had no requirements to pass variables or any information between scripts. This did the job for me:
& "d:\scripts\installwebserver.ps1"
If it can't be done in PowerShell (yet!), there is the option of calling psexec or powershell.exe or cmd.exe directly using Invoke-Expression. MoW talks about calling a process and leveraging the WaitForExit method, which could be useful as well.
.: wi-spy and chanalyzer updated
MetaGeek has recently updated the Wi-Spy software to Chanalyzer 2.1.6. They also have other softwares for the Mac updated. Oh, and I see Wi-Spy now has a 2.4 product which has an external antenna and has ballooned in price to $400. Ouch! Still, the original is available and the software works with both.

I'm not sure the external antenna is worth the price, and at $400, they're really moving out of consumer-land geekery and into a more small office wireless support market. Unless I consult with wireless analysis and site surveys, I don't think any home user will lay down that much money for this tool.
.: security is not useless
Read at least the first few paragraphs of this post on 0x000000.com on how security is useless (wish I could remember who maintains that site, since their name isn't apparent). If we're into security or even have a smidgeon of security consciousness in our IT worlds, we've been there. In fact, I think we all need to hit this low point in the rollercoaster of life regularly. Really, that's the point of what we do, right?

Every time I feel this way about security, I am reminded that skilled attackers are still rare and that security does not have to absolutely protect against them. We need to accept that and be happy with that if we're to continue as an industry or even in our happy lives.

I like to think of security like herding cars, holding sand, or visualizing wind. These are all difficult, if not impossible tasks to do perfectly. That doesn't mean we do nothing. Security is not black and white, perfect or useless; to believe so means a belief in a silver bullet to achieving a perfect security state. (Think about it for a while and what implications there are which follow certain beliefs.)
.: war walking the white house on darkreading
DarkReading has a nice article about war walking near the White House and other DC governmental hubs. This certainly takse a level of moxie to even attempt, as I'm not sure I would even try that.

A few points to pull out. I like the mention of EV-DO and would love to see more security measures and exposures on this. I wonder if there is a way to jam EV-DO signals within your area, but not disrupt normal cell phone technology, for instance on a corporate campus. I like the mention that people (even consultants whom you think should know better) piggy-back on any sort of open wireless network they can get to, even if it discloses sensitive information. And a nice quote:
"Later, Rushing shows me how easy it is for a phisher to duplicate one of these internal 'guest' log-in screens and grab all the traffic from an unsuspecting client. 'I'm surprised we don't see more of that.'"
I'm surprised we don't see more of this either. I think this is simply a bit more difficult for newbies to do, whereas hacking something like WEP has tons of tutorials which can pay off if the newbie is lucky. I like that these topics come up, because while we have this dull buzz in the background about wireless insecurities, it still is nothing more than a dull buzz. A dangerous dull buzz.

Sadly, this article ends on an off note with the following quote:
"'Kids are adding to WIGLE all the time -- it's one of the ways you can look cool,' Rushing says. 'The more APs you've mapped, the cooler you are.'"
If you want to look ignorant and rather retarded, throw a lashout to some useful service and make sure to mention the "kids." Ugh, this was not necessary to an otherwise good article, and really left me thinking that Rushing is just talking out of his ass here.
.: united states to require "botnet" software on all citizen computers
In response to a United Press International report that China has amassed a botnet of 750,000 computers located in the US, the US has mandated a 2-year timeline to force all Internet Service Providers (ISPs) and customers of those ISPs to run government-sponsored botnet-like programs on their computers. All US computers could then be called into service in the event the US finds itself in a cyber war, or needs to protects its cyber interest by launching distributed denial-of-service (DDoS) pre-emptive strikes against its enemies.
A former senior U.S. information security official says there are nearly three-quarter million personal computers in the United States taken over by Chinese hackers.
An unconfirmed US senator has denounced this situation as unacceptable and requires immediate action by the US military and the Department of Homeland Security.

US officials hope that by mandating installed software on US citizen-owned computers, they can call up these forces when needed to form the largest and most powerful botnet in the world, and reclaim dominance of cyberspace. These measures were rushed through Congress and the Senate and have been approved for immediate action.

An anonymous DHS official enthusiastically commented, "Some systems may be put to work cracking password hashes pilfered from enemy systems, while others may scan the Internet for vulnerable enemy systems, and even others can actively be used to attack other systems in the world. Basically, when needed, we could take control of the system in the background, unbeknownst to the user."

He also added, in concern for ISP cooperation, "ISPs will be forced to require their customers to install our software. They risk losing rights to lines and bandwidth, let alone government penalties, should they not comply."

This software in question is nearing completion, and the software development firm, still a highly secretive organization close to Silicon Valley with ties to Washington, DC, will run in the background of Windows and Mac systems, with Linux versions planned for the near future. It has been rumored this organization has been working closely with specialists from the Secret Service and NSA.

The Frontier for Internet Safety is heavily opposing these new revelations from the US government, but so far has had little to officially say until they can view the software. They have also suddenly become the victim of a currently ongoing DDoS, so their site may not be available at this time. The source of the attack is still unknown.
.: jericho 1 - de-perimeterization and the jericho forum commandments
Hoff recently struck a banner in the ground defending the Jericho Forum's concept of de-perimeterization (alebit not the FUD version) and their commandments (pdf). I typically respect what Hoff has to say (when I understand the topic!), so I decided to stick my nose a bit deeper into the Jericho Forum's position and commandments while trying to keep an open mind. I might just learn something!

First in my examination is checking out their front page which explains de-perimeterization. With such a bold placement, this better be the meat of their message; the why and the what. This also turns out to be the place people create first impressions. Let's chunk this a bit.
today the traditional "firewalled" approach to securing a network boundary is at best flawed, and at worst ineffective. Examples include:

-business demands that tunnel through perimeters or bypass them altogether
-IT products that cross the boundary, encapsulating their protocols within Web protocols
-security exploits that use e-mail and Web to get through the perimeter.
This is stating the obvious, yup, business demands tunnel through barriers, products tunnel through already-trusted protocols, and there is insecurity inside the contents of those protocols. Nothing new here for anyone who has been in IT at any time in the last 10 years. Besides, isn't this the point of internetworks, to share through barriers?

Of course, the point of these barriers is to let certain things through and not let others through. Just because a few holes are poked doesn't mean the barrier is useless. If I put doors to my office with a card reader to slow down the press of bodies to get to work in the morning so my guards can keep a visual for suspicious people, should I get rid of those doors because I'm letting people through already? No.

The Jericho Forum has a point when it tackles tunneling "stuff" through the web protocols which are allowed anyway. I guess we can assume no perimeter devices will deeply inspect packets. But still, I see nothing here that truly suggest the "firewalled" approach is either ineffective or flawed, at least by today's firewall standards.

IT IS DANGEROUS TO ASSUME THAT A SECURITY MEASURE MUST EITHER BE PERFECT OR IS OTHERWISE USELESS! That is the message I get when they call firewalls ineffective or flawed. This just means you need deeper inspection or layered defenses. It is dangerous to say we have a trend of de-perimeterization just because we allow talk between networks.
to respond to future business needs, the break-down of the traditional distinctions between “your” network and “ours” is inevitable
This is pure semantics and means nothing. It's a literary method equivalent to taking a data set in statistics and making it paint a glass half full or glass half empty picture just by playing with the numbers. Besides, I don't think anyone in any company *doesn't* think about "their" network and "everything else." There may be more "other" devices in "my" network these days, and vice versa, but so what? That's not an argument for the disappearing perimeter, per se. It's an argument for more defense in addition to the perimeter.
increasingly, information will flow between business organizations over shared and third-party networks, so that ultimately the only reliable security strategy is to protect the information itself, rather than the network and the rest of the IT infrastructure
This is true in a narrow scope, but again, there is still a line that can be drawn between the aforementioned "our network" and the "everything else." This is obvious when speaking about what you own and what you don't own. You can own the lines and cables and gear up to the demarcation for your ISP, at which point the ISP controls the rest. Has this changed and I didn't realize it? Yes, business has to pump data over a third-party (the Internet, duh) and that information should be protected (duh). But that doesn't imply the perimeter is disappearing. Maybe it is disappearing compared to 25 years ago when information stayed inside buildings.

This statement seems to imply that the only recourse is to protect information. This is great as long as we don't need to ever use that information. Once we open that book that is usually locked in a safe, someone can read over our shoulder, snatch it from our hands, or spill something on it. This is not reality.

The Jericho Forum says this is the trend of de-perimeterization. No, this is a trend in needing defense in depth (depth as in layers or even depth as in deeper inspection at the perimeters). Sadly, defense in depth is a common phrase, and I think their reason for using a "new" term is entirely PR and marketing and to get noticed. Well, they have! :)

So let's just assume they still have a valid point, and there is a need. I'll buy that because I think that is true, and I really want to give them the benefit of the doubt. Next, I will take a look at their de-perimeterization solutions, also available on their front page.

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: jericho 2 - the jericho forum and the de-perimeterization solution
I'm going to continue looking at the Jericho Forum's concept of de-perimeterization (god, that's a bitch to type...) and its commandments. In this "chunk," I'm taking the "de-perimeterization solution" section of their main page.
While traditional security solutions like network boundary technology will continue to have their roles, we must respond to their limitations. In a fully de-perimeterized network, every component will be independently secure, requiring systems and data protection on multiple levels, using a mixture of:
I like that they concede that boundary technology will continue to have their roles. They don't stress this enough to address the knee-jerk reaction they get of "oh my god they want us to remove our firewalls!" Sadly, they follow this up with saying every component needs to be independently secure. Ugh...why bother with the first statement, then? Is that network boundary only good for logging now? I think this is a great goal, however, but it should be the juxtaposition of these two ideas: strong boundary with strong systems. This is called defense in depth, which Jericho Forum is seemingly avoiding in exchange for their more dramatic "de-perimeterization" term.
-encryption
-inherently-secure computer protocols
-inherently-secure computer systems
-data-level authentication
That first item is good, but it definitely is a fly in being able to monitor your networks. The role of encryption alone is powerful enough to shape the direction of security for the coming 50 years. They have a big point with this, and if it continues, the effect will be a de-perimeterization for deeper level attacks which we just won't be able to decrypt and inspect without each system becoming an island fortress. Yikes!

The middle two...just make me sigh in bliss. I wish we could do that, but it won't happen. Even things we think are inherently secure today have holes found years from now. This is an ideal, and just won't happen because we're not perfect, but more importantly because it is not economical for most of business. The software and web developer industries are excellent illustrations that there is not enough drive to get things secure up front. The drive is to get things done first, prove that it can make the company money, and later scramble for an SDLC that includes security testing and design near the start. Unless the world turns topsy-turvy in the next 50 years, I just can't see this changing; it's a basic effect of technology, progress, and change.

I'm not sure what is meant by "data-level authentication." Does this mean the data will inherently authenticate users accessing it? I can only guess at this one. It sounds catchy, but could be just empty speak.
The design principles that guide the development of such technology solutions are what we call our “Commandments”, which capture the essential requirements for IT security in a de-perimeterized world.
Great!

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: jericho 3 - the first three commandments: the fundamentals
As I was talking to a colleague yesterday about the Jericho Forum, someone who didn't know about them, it occured to me how "European" this approach is. I guess it might be more accurate to say it is not terribly compatible with typical American approaches. In the US, we hold capitalism and competition very dear. So dear, that we typically choose competition over cooperation. The attitude is "I can do it better and make money," as opposed to "what is best?" The Jericho Forum suggestions greatly smack of the latter. For this reason, I'm not sure the US will ever adopt this early, if ever. Great at innovating! Poor at maturing those innovations.

Moving on to the actual Commandments from the Jericho Forum, I first see they are bookended by some textspeak. This occurs at the beginning:
The Jericho Forum commandments define both the areas and the principles that must be observed when planning for a de-perimeterized future.
Whilst building on “good security”, the commandments specifically address those areas of security that are necessary to deliver a de-perimeterized vision.
The commandments serve as a benchmark by which concepts, solutions, standards and systems can be assessed and measured.
And this occurs at the end:
Conclusion
De-perimeterization has happened, is happening and is inevitable; central protection is decreasing in effectiveness

- It will happen in your corporate lifetime
- Therefore you need to plan for it and should have a roadmap of how to get there
- The Jericho Forum has generic roadmap to assist in the planning
First, the Jericho Forum hasn't led me to conclude these things. Second, I understand this is not a wholistic roadmap to security, but rather a security framework intended to address de-perimeterization. That's a slight cop-out, but ok, I'm willing to accept this.

So, here are the first three commandments, grouped as the Fundamentals.
The scope and level of protection should be specific & appropriate to the asset at risk

- Business demands that security enables business agility and is cost effective
- Whereas boundary firewalls may continue to provide basic network protection, individual systems and data will need to be capable of protecting themselves
- In general, it’s easier to protect an asset the closer protection is provided
The commandment itself is sound, and an extremely common business theme. Same as the first bullet point. I can agree with these outright. The second bullet point, however, gets back to my current non-acceptance of their hypothesis, and as such I'm predictably cautious. I don't know that data should be capable of protecting itself. Since this is tied to the hypothesis, I'll skip it for now. The last bullet point is also dubious. I counter that it is easier to protect assets close when you have a) few assets or b) strong centralized administration of those security controls. But wait...that appears counter to de-centralization everything. Oops! I'd rather not manage 4000 laptops individually like so many isolate islands. This bullet point is a big step back.
Security mechanisms must be pervasive, simple, scalable & easy to manage

- Unnecessary complexity is a threat to good security
- Coherent security principles are required which span all tiers of the architecture
- Security mechanisms must scale; from small objects to large objects
- To be both simple and scalable, interoperable security “building blocks” need to be capable of being combined to provide the required security mechanisms
This second commandment is another no-brainer, although sometimes non-scalable solutions are fine for a company that is not intending to grow out of the solution scale in the lifetime of that solution. Enterprise-level solutions don't necessarily apply to small companies. The other three descriptors are obvious and I do like the commandment itself.

The first bullet point is something that is not mentioned enough, and too often is mentioned as a baseball bat to get your way of doing things. It's a largely non-actionable topic, but it really does matter. Complexity means less people understand what is going on, flaws can occur in the middle of all that complexity, it is not agile, often not scalable, and so on. Sadly, "complex" is a relative term which no one agrees upon except in general principle. The second bullet point says the same thing only inversely: keep things easy to understand. Well, yeah, hopefully!

The third bullet point is part of my minor quibble on this commandment. I don't think everything must scale. This is determined by the company. If this is meant as a framework for the whole world, then yes, I sure would hope solutions are scalable.

The fourth bullet is one I'd love to hear more about as I think I can read it many different ways. Building blocks...like simple components which together form a secure puzzle? Does that affect complexity? Does each building block need to not only be functional but also secure as part of the inherently secure protocols and such? This almost sounds like a "feel good" bullet point that really means nothing and therefore cannot be addressed at all.
Assume context at your peril

- Security solutions designed for one environment may not be transferable to work in another. Thus it is important to understand the limitations of any security solution
- Problems, limitations and issues can come from a variety of sources, including geographic, legal, technical, acceptability of risk, etc.
- Surviving in a hostile world
The first bullet point on this third commandment seems to address my concern above, about solutions being different for different organizations. Likewise, homegrown apps or ways of putting things together in one environment, may not be transferable directly to some other network. That's fine, but doesn't that undercut needing scalability and simplicity? I guess this gets down to, "Is security a commodity product or a customized service?" By having a framework for everyone, I would also follow that with this describing a commodity product. The second bullet supports the first.

The third bullet...eh? I think someone needs to reword that. This commandment and the third bullet mean little alone.

Of note, I really like what "Assume context at your own risk," says to me. It reminds me of things I see on mailing lists repeatedly. A vague security questions answered by 10 people 10 different ways, all of which make assumptions or contextual decisions without really properly asking questions or answering the actual question. Things are different everyone, and we must not assume it is all the same, but instead interrogate stakeholders. Oddly, I don't get the bullet points for this.

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: starting a powershell script with arguments from another script
I previously figured out how to start a PowerShell script from within another script. My next requirement was to start another script that required a variable. This took some trial and error to figure out the arguments need to be outside the quotes.
& "d:\scripts\installwebserver.ps1" SERVERNAME
.: curphey on the art of scoping application security reviews
Mark Curphey has begun a series of posts about scoping application security reviews. Part 1 talks about the business of application security reviews. Part 2 talks about the types of testing. They're good reads, and I'm looking forward to the other parts.
.: jericho 4 - commandments 4 - 8
Jericho...commandments...yeah, I can see the searches that drag people here now...great. I'm continuing my look at the commandments from the Jericho Forum. This is commandment 4 which bears the header, Surviving in a Hostile World.
Devices and applications must communicate using open, secure protocols

- Security through obscurity is a flawed assumption - secure protocols demand open peer review to provide robust assessment and thus wide acceptance and use
- The security requirements of confidentiality, integrity and availability (reliability) should be assessed and built in to protocols as appropriate, not added-on
- Encrypted encapsulation should only be used when appropriate and does not solve everything
Oh boy! We hit some tender spots here! I think the assumption about using open protocols is that the more open something is the more secure. I guess if you fully believe in a strict interpretation of the first bullet point, this makes sense. But I find it a dubious claim to accept across the board. They have a point about things being open. Take Skype for instance. I dislike Skype because I have no idea what their encryption consists of because it is not open. Still, I can accept this commandment as part of an ideal framework, but I don't think that reflect reality.

I don't like bullet 1 at all. Security through obscurity is life; deal with it. Security through obscurity alone is not security. That's the proper usage of that phrase. Utilizing obscurity can reduce your risk. Changing the SSH server port to TCP 23412 will lower your risk, but true, it won't increase the inherent security of the SSH server itself. So strictly speaking, I don't buy this bullet point. Also, there are times where if we opened up a protocol to peer review and acceptance, we'll spend 25 years over-analyzing and trying to provide a consensus, and then look back at the bloated monster of a protocol that results. Yikes.

The second bullet makes me think what we're hoping for are god-like tentacles of protocols on the Internet. I just don't think that is going to work. We need simple, small, extensible protocols. They should be solid, scalable, and work well. Confidential? I don't quite buy that...and I'm interested in security. Take the simple building blocks and secure them. I don't know what bullet three is referring to, so I'll skip that one.
All devices must be capable of maintaining their security policy on an untrusted network

- A “security policy” defines the rules with regard to the protection of the asset
- Rules must be complete with respect to an arbitrary context
- Any implementation must be capable of surviving on the raw Internet, e.g., will not break on any input
Again, I get the feeling we're striving for a framework no one can attain. That's not a good goal. This commandment sounds good on one hand, but one bullet and one implication make this taste bitter.

First, I agree that devices need to maintain their security when away from the nest. My caveat comes when a security policy needs to be updated or changed. What then? Does this not mean a digital form of sneakernet or centralized management? This makes me feel like our devices all need to be like H3 Hummers; tanks driving around the big bad roadways. Ugh.

The first two bullets are no-brainers. The third bullet sounds nice, until that last little bit. Will not break on any input. Well, that's great. Again, a nice ideal, but trying to build perfect devices and security by using imperfect people is a stretch for me.

Next, I'm blocking commandments 6-8 into one section since they seem to cover similar ground.
All people, processes, technology must have declared and transparent levels of trust for any transaction to take place

- Trust in this context is establishing understanding between contracting parties to conduct a transaction and the obligations this assigns on each party involved
- Trust models must encompass people/organisations and devices/infrastructure
- Trust level may vary by location, transaction type, user role and transactional risk

Mutual trust assurance levels must be determinable

- Devices and users must be capable of appropriate levels of (mutual) authentication for accessing systems and data
- Authentication and authorisation frameworks must support the trust model

Authentication, authorisation and accountability must interoperate / exchange outside of your locus / area of control

- People/systems must be able to manage permissions of resources and rights of users they don't control
- There must be capability of trusting an organisation, which can authenticate individuals or groups, thus eliminating the need to create separate identities
- In principle, only one instance of person / system / identity may exist, but privacy necessitates the support for multiple instances, or once instance with multiple facets
- Systems must be able to pass on security credentials /assertions
- Multiple loci (areas) of control must be supported
I'm not really sure how to take these three commandments. It sounds like it would be satisfied with a global identification and trust system. That would certainly be fairly perimeterless! But that will never happen, especially in the US. In fact, it is that third bullet, about having trust levels varying, that make me still believe there are perimeters. When a trust level changes, that's where you put some access control. Network access control. Anyway, I can't be too dogged on these three commandments since I don't fully get it.

So what we have so far is very heart-warming, feel-good idealistic goals for a global infrastructure (extrastructure?) utilizing perfect or near perfect protocols and devices that can withstand anything. Sorry, but what the fuck...?

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: sending emails with powershell
Sending emails with PowerShell is pretty straightforward. Emails can be sent either by default through a normal SMTP server or they can be dumped into a local instance of IIS to be picked up and delivered. Both can be useful depending on the situation.

First, I want to prove I can send email from my workstation through the fictious mail server at mail.server.com. Each of the .Send method arguments can be string variables if needed.
$smtp = new-object Net.Mail.SmtpClient("mail.server.com")
$smtp.send("mike@server.com","mike@server.com","test","test")
$smtp


Host : mail.server.com
Port : 25
UseDefaultCredentials : False
Credentials :
Timeout : 100000
ServicePoint : System.Net.ServicePoint
DeliveryMethod : Network
PickupDirectoryLocation :
EnableSsl : False
ClientCertificates : {}
This next example dumps the email to the local IIS instance. Just change the DeliveryMethod and then send the email as normal.
PS> $smtp = new-object Net.Mail.SmtpClient
$smtp.DeliveryMethod = "PickupDirectoryFromIis"
$smtp.send("mike@server.com","mike@server.com","test","test")
$smtp


Host :
Port : 25
UseDefaultCredentials : False
Credentials :
Timeout : 100000
ServicePoint : System.Net.ServicePoint
DeliveryMethod : PickupDirectoryFromIis
PickupDirectoryLocation :
EnableSsl : False
ClientCertificates : {}
I consider this a major part of scripting of any type: notifications. It is not necessarily enough to just log something if you never check logs. I'd rather throw something to the foreground, which includes an actual error, or in the case of a daily notification that a script has run, a quick email to my Inbox. This can even complement logs, such as with a log tail script that emails on certain events. Among many, many other uses.
.: jericho 5 - commandments 9-11
Continuing my smallish review on the Jericho Forum commandments (pdf) and their concept of de-perimeterization, I have just three commandments left, all under the category, "Access to data."
Access to data should be controlled by security attributes of the data itself

- Attributes can be held within the data (DRM/Metadata) or could be a separate system
- Access / security could be implemented by encryption
- Some data may have “public, non-confidential” attributes
- Access and access rights have a temporal component
This sounds like a Mandatory Access Control system where data contain attributes which determine access and use. This is a bit odd, since I have only heard of this system used by governments (classified, unclassified, top secret...).

This also sounds like DRM, which, nicely enough, is mentioned by term in the bullets! One problem with DRM and metadata is forcing adherence to the metadata or DRM (let's call it collectively DRM for my own sake). What if you have metadata that dictates FileX should only be used by 15 people. What if I come in and read FileX but decide to ignore the DRM tags? Is this another form of encryption? Why can't I just leverage the DRM to get the data and then move it elsewhere as a copy? Sounds familiar? It should, since we're seeing how useful or futile DRM processes can be with media and copyright.

MAC has worked for the government and military for a long time, but I think that has to do with a) the rigid discipline of the military and secret organizations, and b) the long-term habitual, forced use of it. Can this be as rigid and forced globally? At this point in time, I can't see that happening in the foreseeable future.

Overall, oddly, I do like this commandment. Even if I don't buy into the specified mechanics, I agree we need to focus on data. Not to the exclusion of the network or systems, but focusing on the data needs to be part of the security equation.
Data privacy (and security of any asset of sufficiently high value) requires a segregation of duties/privileges

- Permissions, keys, privileges etc. must ultimately fall under independent control, or there will always be a weakest link at the top of the chain of trust
- Administrator access must also be subject to these controls
Hoo-boy..this is a tough one. This commandment pretty much ensures that data protection solutions will be complex. Ultimately, you do need someone who turns the keys when it comes to protection. Maybe two people, or three, but someone somewhere will either have the power or a collusion of forces will have the power. And that's in extremely complex setups for separation of duties/privs.

But even if this commandment is complex and maybe ultimately not of interest or achievable to most organizations, this is a good guideline to try to achieve. Most everyone has domain admin credentials and a need to create accounts in an organization. These tasks/privs can be separated to various people with various auditing and authorization chains.

Is this scalable for small companies with 1 IT person, or even medium-sized companies? Good question, and likely not. Even in my current team of 5 network guys and 3 desktop guys, we really don't have the corporate interest in slowing down our processes to achieve this idea ultimately. We do so for a couple tasks and privileges, but otherwise it is just not worth our time to figure out.
By default, data must be appropriately secured when stored, in transit and in use

- Removing the default must be a conscious act
- High security should not be enforced for everything; “appropriate” implies varying levels with potentially some data not secured at all
In other words, default should be secure. If you want it less secured, you have to choose to unsecure it, or back down on the security controls to an appropriate level. Sounds good to me, although I think this commandment is much more attainable in closed networks, i.e. networks with boundaries.

Oh, wait, hold on...did I say networks with boundaries? Yup! Networks with perimeters! Without perimeters...well, that means either the whole Internet needs to run on new protocols (which I believe the Jericho Forum would like to see happen) or we need a global IPSec (or encryption/PKI) setup that is trusted by all. Ack.

Of interest, it seems this is the only commandment that allows some leniency. Someone determines what is appropriate, rather than blanket, rigid statements like most of the other commandments. Quite interesting to have a subjectivie commandment in here, but still appropriate.

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: jericho 6 - my conclusions
I've been checking out theJericho Forum commandments (pdf) and their concept of de-perimeterization. I'm happy to have taken the time to sit back and examine their material posted. Whether I agree or not, it is useful to examine discussion and what other groups think.

1) I stand by my intial thoughts that the concept of "de-perimeterization" is old. I really bet this concept is rooted back in a time before deep inspection firewalls, and maybe even before stateful firewalls. The term is unfortunate and likely needs to be changed, unless they are using it just for the attention. If so, it works! :) But otherwise, I don't buy that de-perimeterization is the future. Sure, maybe borders of yesterday were nice and square like the state of Colarado. But today and maybe into the future our borders will be more complicated like the islands of the Nunavut Territory in Canada (am I the only one who missed the Northern Territories being split? And does that mean I don't know my geography? ...the flaw in quizzing adults about geography and generalizing the result down into child education values...). Nonethless, there are still borders and we will always have a perimeter of some sort for as long as we need any type of centralization management of systems or data.

2) The commandments do make for an excellent ideal. A possibly unattainable ideal. I'm dubious about the scale of such solutions, and I really think this framework only works on a very large scale. Anything below it really can't be bothered.

3) On the other hand, this framework does include excellent guidelines and "rules." Even if they are not followed to a letter, they are rooted in solid digital security concepts. We should keep them in mind no matter what ultimate framework we follow.

4) Likewise, I really think all security professionals should review what the Jericho Forum is saying, and I'd love to attend a presentation some day for even more clarification and discourse. As sec pros, we should be able to discuss such things and keep an open mind about other viewpoints. Besides, if there was an ultimate and perfect solution to our problems, I'm guessing we'd have happened upon it by now and all been wowed to the point of tears. But we're not, and as such, any and all approaches tend to have strong points and good ideas.

5) In the end, do I care about this framework itself? Not really. It's a great exercise, but not really actionable for me in a smaller company beyond just being informed.

jericho 1 - de-perimeterization and the jericho forum commandments
jericho 2 - the jericho forum and the de-perimeterization solution
jericho 3 - the first three commandments: the fundamentals
jericho 4 - commandments 4 - 8
jericho 5 - commandments 9-11
jericho 6 - my conclusions
.: i blame you for whatever went wrong to me today
Articles like this one about DHS looking to investigate a government security contractor illustrate some of the crap (normal business activity) that occurs in our industry. I'm not going to presume I know the full story or what was in the original contract or what Unisys' opinion is, but I think this article illustrates two painful realities.

1. If DHS is attacked and they have someone to blame such as a contractor who should be taking care of things, the blame can and likely will be shifted, rightfully or not. This basically means the "information age" is not just surging along and pulling culture with it, but business culture is requiring information be saved and documented to avoid he-said-she-said crap. So unless Unisys goes the proverbial extra mile in the contract and also documents all deviations or obstacles, and because security will always eventually fail, there will always be a scapegoat. And blaming everyone else for responsibility for things is a hallmark of the 90s and 00s. (All starting with the McDonald's woman who spilled hot [no shit?!] coffee on herself and successfully sued.)

2. The government is opening up competing bids for the contract. That means we have a major differentiator being cost/price. And we all can guess how the quality of security may follow the line of price. Lowest bid will almost certainly ensure the security is also of lower quality.
.: switch basics: loading up a wiped cat 2950
Holy crap 9600 baud is slow! I'm doing something different in loading a wiped switch, and I thought I would use an xmodem transfer. Go me! Since this is taking so long, I may as well post some switch basics as I go. (To note, my earliest speeds on the Internet were 14.4kbps modems back in high school.) I'll also go ahead and put on some background music, the excellent Dubnobasswithmyheadman album from Underworld (a favorite!).

I have a completely wiped Cisco Catalyst 2950T switch. Even the flash has been erased (an eraser of love). If you boot it up, it gives an error and stops pretty quickly. A quick "dir flash:" will show nothing. I also have an ios version ready and waiting: c2950-i6k2l2q4-mz.121-22.EA8a.bin. For my console system I have an old Dell Latitude laptop (yeah, it's one sexy-small laptop!) running a permanent install of BackTrack2.

To get the c2950-i6k2l2q4-mz.121-22.EA8a.bin file to BackTrack2, I decided to also test my tftp server and use tftp to transfer the file. My tftp server is at 192.168.10.108.
tftp 192.168.10.108 -c get c2950-i6k2l2q4-mz.121-22.EA8a.bin
Gosh, that's easy. Now I need to connect up to the switch by plugging in necessary cables, including the power so that it powers on and loads. I decide to use CuteCom in BackTrack2 as my graphical terminal emulator. I change the baud rate to 9600 and click Open device. I type a few commands to get ready for my transfer.
switch: flash_init
Initializing Flash...
...The flash is already initialized.
switch: load_helper
switch: copy xmodem: flash:c2950-i6k2l2q4-mz.121-22.EA8a.bin
Begin the Xmodem-1k transfer now...
At this point the terminal is waiting for some data. CuteCom has a Send File button at the bottom where I can select the file and start transferring at the blistering 9600 speed! In fact, after writing this, I'm still only up to 15% completed. Ahh the joys of a wiped device that doesn't even know what an IP address is yet.
.: emulate cisco routers
Emulate some Cisco routers on your laptop using Dynamips. This looks awesome! From Andrew Hay.
.: when terminal/server is reinvented as desktop virtualization
Ever read an article that makes you kinda stop anything else you're doing as you try to make sense of it? Then read it again, which doesn't help...then read it in bits and pieces to see if you can make sense of the parts in order to tackle the whole? And then maybe still wonder what sort of crack the author is on? I had that this morning reading an eWeek article, Analysts Predict Death of Traditional Network Security. I guess there's a reason I didn't re-up to eWeek a few years ago. And it is just coincidence that the topic is de-perimeterization and mentions the Jericho Forum, I swear!
According to them, in the next five years the Internet will be the primary connectivity method for businesses, replacing their private network infrastructure as the number of mobile workers, contractors and other third-party users continues to grow.
...So the Internet is not already a primary connectivity method? I guess I underestimate the Frame Relay and dedicated links market dramatically!
One of the end results of the death of traditional network security will be a growth in desktop virtualization, Whiteley said.
Hey, that's kinda cool to read. In fact, we're right now doing some desktop virtualization for mobile employees, particularly developers offsite. They VPN into our network with a system, then Remote Desktop into a virtual machine on our network upon which they work. Odd...I never once thought of this approach as being part of de-perimeterization or the death of the nebulous "traditional network security." It's a way to avoid bandwidth restrictions and data egress.
Desktop virtualization allows a PC's operating system and applications to execute in a secure area separate from the underlying hardware and software platform. Its security advantages have become a major selling point, as all a virtualized terminal can do is display information; if it is lost or stolen, no corporate data would likely be compromised since it wouldn't be stored on the local hard drive.
And this is where we finally stop toeing the brakes and actually put some pressure down on the pedal. I don't think the author was involved in something called terminal/server architecture before, since that's what he decribed. He did not describe desktop virtualization. Maybe we're seeing the bastardization of terms...which is unfortunate. There is a point to be made about moving to virtual desktop systems and also moving back to terminal/server setups, but it really has nothing to do with de-perimeterization or the use of the Internet to connect businesses. It has to do with support costs, desktop OS compliance activity, and data security. All of which are vague and ubiquitous enough to "support" pretty much any security theory or initiative. Part of my religion is predicated on you breathing regularly. If you breathe regularly or believe in breathing, then you support my religion. Um, no.
The adoption of PC virtualization would mean companies would no longer have to provision corporate machines to untrusted users, Lambert said. Desktop virtualization simply equals a more secure environment, she said.
Hrm, I don't follow that reasoning at all. In fact, this is a three-punch combo in confusion. People provision computers to untrusted users? Desktop virtualization means you don't have to provision anything now? And somehow that makes things all more secure? I'm feeling nauseous...

I think the author and the people quoted in the article (Forrester analysts) need to take a step back and iron out what they mean by desktop virtualization and how that compares to the age-old terminal/server environment, and move forward from there. But some of these conclusions just don't follow, and the muddiness of the terms and logic makes the article a waste of time.
.: unisys and dhs security debacle
The other day I posted about Unisys and the DHS. After seeing a post from Bejtlich, I see they're fully wading into it together. Ugh.

While I won't defend Unisys, I'll play Devil's Advocate for just a moment. Was Unisys just providing the systems and process and DHS was meant to actually put things into operation? And I wonder if there were any obstacles imposed by DHS that prevented things like IDS systems being implemented? I know it can be a pain when you're asked to install ABC onto 45 systems, but half of them keep telling you they're too busy and to try again next week.

It obviously sounds like Unisys made some really poor decisions, but I'm curious on the extent of them from Unisys and from DHS itself, if any. Thankfully, this is the transparent government and not private companies, so we get to watch the laundry shake violently in the wind.
.: the linux file system
This image of the Linux file system is extremely cool! I think I'll print a few copies out and put them next to my computers. Layouts are one thing, but to make a useful one with some instruction on what some of the more esoteric section are is excellent!
.: how do you eat your 0day?
There is an interesting discussion this week on the Full Disclosure mailing list about the definition of "0day." Oddly, what seems like an old term is definitely not a term with an understood and universal definition. It seems to vary widely, dramatically widely. Then again, FD is a fairly argumentative list with some people arguing anything just to argue. Still, it is interesting the lack of clarity in some of our widespread terms.

My take on 0day, which I've used ever since I first heard the term many years ago, is pretty much the same as the Wikipedia entry. To me, a 0day is an exploit released before solutions or patches have been diseminated from a vendor. This wouldn't mean a new strain of a virus exploiting a known vulnerability would be a 0day. But a new worm exploiting a new vulnerability would qualify. A side effect is whether something is a 0day to someone who has seen it, and provided for a workaround, even though they're not the vendor. To me, 0days are somewhat unstoppable exploits, mitigated by defense in depth / layered defenses.

And don't even bring up "less than 0day," as I feel dumber each time I hear that term...
.: some logging notes
Cutaway has an excellent interview up with Michael Farnum who talks about his experiences with companies in regards to a number of things, namely logging. Does he see companies logging, are they doing it properly, and so on. Excellent insight into what's really going on, and not as untrustworthy as a sheet of stats from some vendor with an agenda.

In reflection to the questions and answers, here some of my bullet points when it comes to centralized logging discussions.

1. The IT team needs to see value in the process of logging and reading logs. If they don't see value, they either won't do it, won't do it properly, or have no clue how to leverage it. If they don't see value and the business sees no value, it just plain won't get done. This probably always ends up not being a security value-add, but rather an operations one. Something went wrong with a web app, can you troubleshoot it by looking at the logs? Or a server isn't updating properly from WSUS...and so on. Logging should be seen as important as a heart monitor on a patient in the hospital.

2. Once there is value, or maybe even before the value is realized, admins need the time to properly get things set up. Having enough time to gather Windows event logs and nothing else is going to be a wash. Same with just gathering the logs on half your firewalls. Give the team enough time to properly get things going.

3. Set aside time for the admins to regularly look at logs and maybe even "play" with the logging server. If admins don't have time or are not allowed to use the logging reporting and querying regularly, they won't have the familiarity to do it when emergencies or high profile incidents arise. Practice, practice, practice.

4. For the love of whatever, read Anton's paper(s) about the six mistakes of logging.

My own logging? At home, I don't do enough. At my last job, we did logging, but didn't use it enough or probably use it properly. At my current job, we don't do enough logging at all.
.: the security silver bullet syndrome in negative exposure
It's not often someone hits a pet peeve of mine dealing with security, but I bristled at one just now.

One of my tenets of security is to make sure to not believe there is a silver bullet or security panacea. I think we universally believe that.

But there are insinuations and beliefs that, in a way, are saying there really is a silver bullet. Most of these have to do with saying "Security measure X is not 100% effective, therefore it is useless/inefficient/expendable."

I've seen this with Jericho Forum defenders who say the perimeter is porous now, which must mean the firewall is less efficient, which must mean we're moving towards no perimeters. "What use is a perimeter defence with holes in it after all?"

Such a statement is analogous to saying, "I expect my security measures to be silver bullets."

I don't think I've stumbled downhill nearly that violently since breaking my leg sledding one winter...
.: secutor prime examines desktop compliance checklisting
I currently don't do much desktop work right now, but it is still nice to see how a system compares to various standards. I'm not sure where I picked this up yesterday, but I got pointed over to a tool, Secutor Prime, which examines a system and compares it to various standards such as the FDCC. The best part of this tool is the feedback. Clicking on any check will give the findings and also the steps needed to pass that particular test. An excellent means to learn more about desktop security, the settings, and what compliance checklists look for.
.: interview with rfp
RainForestPuppy (one of the coolest names ever) wrote a memorable memorandum a few years ago. I've mentioned it before. That memorandum holds a special place in my mind, and I'd definitely buy this guy a few drinks if I were to ever meet him.

Infiltrated recently posted an "interview" with RFP.
.: installing pidgin 2.2.0 on ubuntu 7.04 to use google talk
I recently decided I needed to use Google Talk. I don't know why, but I have Gmail accounts, so why not buddy up to Google Talk? I use Pidgin 2.0.0 on my Ubuntu 7.04 laptop. Unfortunately, I was having no luck getting XMPP (Google Talk) to connect properly. An upgrade to 2.2.0 is in order, right? Unfortunately, nothing exists in the repositories to upgrade Pidgin. Great! When I did the following steps, I did not have to remove my old Pidgin installation, and all settings and buddies were carried up just fine.

First, I need to update my repositories list:
sudo gedit /etc/apt/sources.list
with:
deb http://repository.debuntu.org/ feisty multiverse
deb-src http://repository.debuntu.org/ feisty multiverse
Then run the following commands:
wget http://repository.debuntu.org/GPG-Key-chantra.txt -O- | sudo apt-key add -
sudo apt-get update
sudo apt-get install pidgin
sudo apt-get install pidgin-libnotify
After this, Pidgin can be started from Applications -> Internet -> Pidgin. Once the app has started, I want to connect to Google Talk. Accounts -> Add/Edit -> Add -> Google Talk.

My protocol is XMPP by default. Screen name is my Gmail login. Domain is gmail.com. Resource is left to the Home default. In the Advanced tab, I checked Require SSL/TLS, chose a connect port of 5222, and connect server talk.google.com. I left the Proxy type to Use GNOME Proxy Settings.

References
installing pidgin 2.2.0
connecting to google talk