Mr. Buddha, Mark Curphey, mentioned dashboards recently, which got me all giddy at the link he provided to a site about information dashboards. I love me some dashboards. I love them enough that I have a section of my menu on the right devoted to security dashboards. Dashboards are used to distill relevant information down to a, hopefully, more visual representation of your reality. Not only that, but have you ever had someone in the management chain above you go gaa-gaa over the pretty pictures and lights and trends on your desk, even when they have no friggen clue what it all means? People seem to react positively to seeing things like this on a network or security admin’s desk. At a previous job, I didn’t get too many people walking by wondering what I had up my sleeve for that day, but whenever I turned on a dashboard, I had plenty of people from various job roles wander over and ask what all the lights and colors were for and how “cool” it was. In my mind, it has become part of selling oneself as a technical and security expert.

Now, I want dashbaords at home, someday. I don’t know if I will ever become proficient enough to roll my own, but I have plenty of spare systems and monitors around to utilize their extra cycles to display neat metrics and dashboards. Due to my current refusal to “settle,” I don’t have big furniture in my apartment like a desk or two, so the whole dashboard setup needs to wait a bit more.

But I thought it worthwhile to write down, for myself, a bit of a wishlist on dashboards I’d like to see on my desk over time. Note that this is at home, although many of these things should be able to scale up to enterprise use. Suggestions for tools are welcome.

• visual traffic monitoring – like etherape or eve or plenty other tools that give a pretty view of what and where traffic is on the network.
• less visual traffic monitoring – like a tcpdump scrolling by on a monitor; only tailored down to watch only things really important (and not my workstation streaming web radio…)
• traffic summary – a summary of traffic levels to web, mail, VPN, SSH servers and so on; even as pared down as simple daily log file sizing.
• system monitoring – on a basic level, what is up and what is currently down. On a deeper level, system health such as CPU, RAM, and disk usage, running processes, and so on.
• service monitoring – on an even deeper level, any time traffic to something comes in it can log, throw a visual cue, or send a quick message, for instance a login attempt on SSH or VPN.
• arp watching – roll your own basic NAC rogue detection on a network by monitoring arp requests in a DHCP network, using arpwatch or arpalert (I think those are the names).
• security monitoring – tripwire-like integrity detection on important systems, account creation events
• IDS – things like Snort alerts, although these aren’t as useful on a dashboard, per se.
• threat/vulnerability/external – It is nice to monitor one’s own realms, but none of us are islands. We need to know about changing threats, new vulnerabilities, or maybe some trend or new attack vector affecting the security health of the Internet as a whole. There are plenty of these sorts of dashboards available, since they lend themselves well to the web.
• wireless – kismet just to keep an eye open for new clients and the wireless network in the area
• wireless spectrum analyzer – run the pretty Wi-Spy tool in a corner to monitor the health of the wireless frequency range.

Ok, so all of this is pretty personal to me, because I am a firm believer in keeping one’s fingers not just in the trenches of the back room, but making sure they are constantly feeling for a pulse, temperature, clamminess, etc. So much about security and IT in general has a fundamental base of monitoring for changes and abnormalities. It’s the part of me that is a control/information freak which lends itself well to the field. And yes, I like having a few non-screensaver’d monitors around me showing me what is going on at all times.

Workplace geek humor time! One of those sounds that just always makes me grin in eerie pleasure when sitting in my cubicle is the sound of print job white noise unceremoniously turning into a printer quietly eating the paper. Not just printing, but jamming up and eating the paper; the pleasant crinkling that indicates things are not well…sure to give me a grin!

Bonus points if someone walks over in the next 15 minutes and starts swearing softly and sounding like they’re banging every lid tray and movable plastic piece on the printer…that sadistic side of geek humor, that!

There is talk about the iPhone’s implications to security. I think it is important that anyone discussing this make it clear where their perspective lies: from the eyes of an autonomous home consumer or the eyes of corporate IT. From the eyes of a home user, my condolences, but I really expect this device to be no different than any other, and likely exploitable. For the business perspective, this is no different from any other phone or USB key fob on the market.

• 1. Limit/disable USB/Bluetooth ports on your laptops and desktops.
• 2. Only officially support the use of approved devices, of which there should be few, and they should be manageable from something like a BES server.
• 3. Make sure you know what MACs are on your network, and if an iPhone is able to get onto your Ethernet network, be sure you have alarms and possibly port security on your network.
• 4. (Optionally) Disallow, by policy, the use of home phone devices to transmit corporate email to and from. You might not be able to effectively audit this, but you better let people know they shouldn’t be doing it in the event you find out they are.

If you don’t already do the above corporate security measures, you have no business worrying about the iPhone. If you already do the above corporate business measures, you have no business worrying about the iPhone beyond deciding how long to wait before allowing it as an approved device for syncing and official use (or when to put the final “PERMA-DENIED” stamp down.

If you didn’t think auditing and security was going to be a growing field, add this to the reasons you should stop being naive. ComputerWorld posted a series of questions and requests reportedly made by HHS to Piedmont Hospital as part of a (surprise?) HIPAA audit. Keep in mind that it seems Piedmont only had 10 days to submit the answers. That basically means having it all done and ready, not trying to slap it together during a couple 120 hour weeks. (And even if they did that, any even minor interview with IT techs will reveal the wide-eyes and confusion about the superficiality of anything slapped together.)

Likewise, if these questions don’t make you gulp at least a dozen times, you might be living in a dream world. Lots of people talk about security enabling business and ROI and things like that, but there is still going to be a growing field of people just taking care of the back rooms, because these things simply cannot be tacked onto “enabling” projects or expensed properly by a project or business initiative.

I am also very confident that these questions en masse cannot and never will be answered or tracked by any one product no matter how unified it is. Technology changes too quickly and there is too much of it. By the time products dig in and solve something like Windows 2000, then Windows XP is released. And then Vista. And then wireless. And then new attack vectors arise like wireless driver attacks, plus “arguable” attacks like DRM-justified rootkits. And then businesses that simply have to retool their infrastructure every 4-5 years, plus all the homegrown glue that holds everything together. And the changing landscape of almost every business. And the fact that while each company only has a handful of problems when it comes to IT, there are unlimited solutions free and commercial… Oh man, headache…!

A product can never do all this, nor can a CSO/CISO alone. There will continue to be backroom people, unless we want to just do security on a superficial surface level or make our networks much more homogenous such that Company A’s setup is almost exactly the same as Company B’s setup. No product can do that, although you can argue that service providers may have a chance…but no service provider will be able to scale up to provide for every company even in their own city, let alone make a dent on larger companies or on a wider scale.

I know I’m slightly keeping Rothman in mind when I say the back room is not going away, but I firmly believe all of this just goes back to being as pragmatic as possible when managing security. I still need to get my hands on his book… 🙂

Update: I know that these questions may be no different than people are being treated to with SOX and HIPAA, but still, how many have really been able to take either of those 100% seriously and adhere to them? Like PCI, it’s all about the teeth…maybe cyberinsurance will add the teeth, I dunno. But I would amateurishly estimate that 98% of all businesses would have major infractions from any audit performed, PCI, SOX, or HIPAA.

Dan Morrill pointed over to ComputerWorld’s annual best places to work survey. I clicked the list of 100 companies expecting to see ComputerWorld advertisers, the same old big guns like Google and Microsoft and Yahoo!, and others large companies that can have lots of day-to-day IT grunts write in praises on the surveys (seriously, there are tons of little surveys on Best Company for ____ that are simply getting 80 of your own employees to write in and overwhelm the voting…), but, I was pleasantly surprised to continuously say, “who? who are they? huh?” to many entries. This intrigues me a lot, and makes me kinda wonder what some of these smaller, unexpected entrants do with their IT operations and workforce to be such good places to work. Almost anyone should be able to take the top 20 in this list and get good material from them for case studies… Any by “smaller” I mean smaller than the biggest companies that I expected.

I really think there are many, many smaller and start-up type companies that are amazing places to work for, especially if they have predictable income (which sometimes is tough because so many want to be Yahoo rather than a long-term small company that maintains a solid existence without trying to eat the whole cake…). Hrm, yes, I still have a bug to find something better…

Anyone know anyone at Google or in the Omaha area with any ties to Google’s expansion to Council Bluffs? That’s not really a place I care to live (I’m originally from Sioux City about 90 miles up the river although I live in Des Moines now), but a stint at Google? That’d potentially be pretty sweet. And really, the Omaha/Council Bluffs pair is not a bad place at all.

There’s a bunch of different ways to play with the registry in PowerShell. My latest script snippet that I wanted to preserve on here deals with a couple ways to add registry keys and values. For as cool as this is, however, I don’t believe PowerShell is able to make such changes to remote registries without using other methods. When in doubt, I guess I could just Invoke-Expression psexec.exe someregfile.reg and have it done there, but hopefully PowerShell gets remote registry scripting ability eventually, as this would be the next way to script mass registry changes to people beyond Group Policy.

The Swear Jar (work safe) (heard this in the office and also from FurryGoat). Seriously, if you can’t have this bit of fun in your office at some point, I wouldn’t want to work there. People don’t do great things by being in an oppressive or unfun environment. Hell, people just aren’t optimally productive in such environments. (Ok, minus the lobby area announcement, hehe.)

As I’ve been doing a heck of a lot of PowerShell scripting the past few weeks at work, I’ve come to re-appreciate the comfort of being able to work in a very bounded environment. Network/Systems/Security work is pretty damned unbounded, but when you work on a programming or scripting language, you don’t have to necessarily sweat the scope or mechanics because they’re created for you, for the most part. You deal with the basics, loops, variables, moving data around, manipulating data, reading and writing to objects, and so on. It’s like putting together a jigsaw puzzle; there’s something comforting in the ability to focus. Plus the immediate response/results of scripting are really nice.

I stayed away from scripting, and more appropriately, programming when I was in college and just out of college because I didn’t want to find myself being a kickass XYZ programmer and only a kickass XYZ programmer while languages A, B, and C flew by. Maybe in another life or a future career opportunity will open up a more dedicated scripting/web dev job opp. I think I could live with that, honestly. I think it would have to be a smaller company, though, rather than just being the builder of Function A in Large, Slow, Non-Creative Company.

Maybe that’s why every couple years I perform some deep rework on my web pages, or have an affinity towards scripting. Once you know the mechanics and syntax and keywords of a language, it is all downhill from there (at least for me, since the logic comes easy to me). Braindump Ruby on Rails into my head, and I could probably have a lot of fun with that language, as much as Neo with Kung-Fu.

Anyway, my PowerShell snippet today involves deleting services. Creating services is pretty easy in PS, but deleting them was left behind for WMI to pick up. And no reboot is required. (Unless you have a service open at the time you attempt to delete it, in which case Windows will hang on that and hold the service for deletion until you reboot…so make sure you’re not working in the service anywhere before you try to trash it.)

$service = gwmi win32_service | ? {$_.name -match "ServiceName"}
$service.delete()

Since this is short, I tend to do this manually, and I try to always make sure $service returns the proper service by calling it once just before the delete. And you do this to remote computers by adding “-computer ‘computername'” before the pipe (and with double quotes instead of my grammatically correct singles).

Another interesting list, this one on 10 reasons why the Black Hats have us outgunned. I won’t hit every point, but here are a few things I want to add.

Becoming a Black Hat is a career option even for those who are not super geeks. Very true, and we can see this in the news reports of the people who get caught. They tend to be on the fringe of being a geek, really, especially the stupid spammers. They don’t strike me as particularly skilled at anything beyond their one opportunity and a few tools (hence maybe why they get caught!).

Not all businessmen are entirely averse to the odd hack (on a competitor) I truly wonder exactly how many executives and “high-powered” business persons have a true level of morality. I doubt many do. I expect many have fudged numbers, told white lies, and done some less-than-ethical leveraging and information gathering. When you have money and power at your disposal and you need to protect both, I think a lot of people slide down a rather immoral slope very quickly. If I were a multi-billion-dollar company in a major city with interests to protect, would it be much skin off my teeth to hire someone to sit at the airports all day and “probe” the wireless travelers? Or maybe at my competitor’s airport? I still expect this “career option” to grow, whether I agree with it or not.

I’ll always say I like lists. C-levels like lists, average people like lists, techies need to like lists. 🙂 Over at ZDNetAsia, Scott Montgomery, global vice president for product
management at Secure Computing, gave his take on 4 damaging security habits in the corporate world. Here are my responses/takes. Overall, I like this succinct list, and with minor quibbles, it’s a good list.

1. Fixed Passwords – Fixed passwords, in my mind, are adequate. They aren’t the best practice and best thing to use, but they are still by far the most economical for most corporations and people. We know passwords, we’re used to them, and they tend to be just fine when properly complex and rotated. If one-time passwords were so useful, why are they so difficult to roll out or scale up to our needs? They are because you need a lot of levers and gears aligned in a corporate environment to be able to effectively implement such solutions. No single-sign-on possibility in your shop? Then one-time password tokens are not yet for you.

2. Neglecting inbound threats from e-mail, the Web and instant messaging – Montgomery gets this one correct, and not much I can add to it other than nitpicking about the term “threat” used for an attack vector.

3. Forgetting that data traffic is two-way – I think this is another good point, although I think we can all admit trying to get our arms around egress is like trying to hold down a very large bear or herd cats. I think that is a major reason so many of us are behind here: we have other easier things to tackle. But certainly, we should keep this in mind. But always think about this: how do you stop me from uploading data to a web server that I own? How do you stop me from uploading data through an encrypted channel on port 80 outbound? These are difficult to stop in many shops, without spending some good money on solutions. Hence…they do get left behind.

4. Not encrypting data – I don’t like bashing lack of encryption by using email as an example. Sadly, SMTP is broken and obsolete, but like the SSN, it is so widely used and relied upon… He also dives very deeply into the FUD by saying unencrypted mail is public like a paper. No, it’s not, but he still brings up a good point. Encryption should be used whenever possible on the wire, and on the disk. We’ll only slowly move in this direction due to compatibility issues.

I’ve had an SSH server up for some time on the default port 22 tcp on a Windows box. The other day I finally moved it over to a virtual Ubuntu box where it will stay indefinitely. While SSH was running on Windows, I logged all failed attempts. I didn’t expect Amsterdam to outpace Asia! Also, I suspect these were all automated attempts since root was tried the most. Using Cygwin on Windows, I don’t have a “root” account. In fact, “Administrator” was never even attempted once (what the hell?). Go figure.

This brings me back to a recent thread on the Security-Basics list hosted at SecurityFocus where a lot of people got pretty heated up about whether changing the default SSH port or using port knocking is an effective security measure. There were impassioned responses on both sides of the equation, and in a way, they were all somewhat correct. But I think it is more accurate to say changing the SSH default port is not a security enhancement, technically, but does reduce the risk of that service. Risk is decreased, and in a more high-level way of defining “security,” the security of the box was increased. This does not mean SSH became more secure or the box magically became more secure… Really, it just came down to semantics (mostly).

The stats above help illustrate that risk my SSH server faces. If the SSH port had been moved, I would honestly be surprised if I had a dozen failed login attempts. That illustrates reduced risk. I’d also be able to identify my threats a little better. Someone with 5 failed attempts on my obfuscated SSH port may indicate a targeted attacker as opposed to an automated worm scanning for SSH. If someone was able to port knock my SSH open to make failed attempts, that might perhaps indicate my port knock sequence was sniffed somewhere or an insider is atetmpting something fishy.

I’ve been doing more scripting lately, and thought I should document (for myself) some of the stuff I’ve been using. Rather than spit them out here, I put them on the wiki. Here are some snippets of what I use. We use these scripts when building new development environments and servers. Nothing ground-breaking, but still useful as inspiration if anyone else is working around PowerShell.

Create Windows services
Building LDAP container and object strings
Process and create OUs
Create an Active Directory Group
Create an Active Directory User
Open and search XML files

Couple quotes I like. Andy already mentioned one, but I thought I would mention it again along with the previous days’ quote on our Art of War calendar.

“When your strategy is deep and far-reaching, then what you gain by your calculations is much, so you can win before you even fight. When your strategic thinking is shallow and near-sighted, then what you gain by your calculations is little, so you lose before you do battle.” The Art of War, Chapter 1 On Assessments

And…

“When the army is old, the soldiers are lazy, and the discipline and command are not unified, this is an opponent that has already lost.” The Art of War, Chapter 4 Formation

This morning I decided to replace part of a script I own at work with a random password generation function. This was easier than I thought it would be. This function takes a number that should be greater than 4, and returns back a random password of that length. The character sets are pretty obvious inside the function and can be adjusted as needed. The password generated assures the first 4 positions will always be a number, capital letter, lower case letter, and symbol, respectively, to meet some complexity requirements. The rest of the positions are a random character chosen from a random character set.

function RandomPassword ([int]$intPasswordLength)
{
if ($intPasswordLength -lt 4) {return "password cannot be <4 chars"}
$strNumbers = "1234567890"
$strCapitalLetters = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
$strLowerLetters = "abcdefghijklmnopqrstuvwxyz"
$strSymbols = "!%^&*()+=/?{}[]~,.<>:"
$rand = new-object random
for ($a=1; $a -le $intPasswordLength; $a++)
{
if ($a -gt 4)
{
$b = $rand.next(0,4) + $a
$b = $b % 4 + 1
} else { $b = $a }
switch ($b)
{
"1" {$b = "$strNumbers"}
"2" {$b = "$strCapitalLetters"}
"3" {$b = "$strLowerLetters"}
"4" {$b = "$strSymbols"}
}
$charset = $($b)
$number = $rand.next(0,$charset.Length)
$RandomPassword += $charset[$number]
}
return $RandomPassword
}
RandomPassword 36

No doubt there are other functions and solutions to this, but I kinda just wanted my own.