• 05Oct

    2052055757_4e13e12c03I’m excited to say that The Barking Seal Blog has been around for a year now! We’ve had a great time blogging, ranting, and pontificating on the future of IT infrastructure, and have especially enjoyed the reader comments and emails.
    Below are ten of our favorite posts from our first year – if you missed one, check it out now…

    Here’s to lots more entertaining (and hopefully insightful!) posts in the year to come!  Thanks for your comments, feedback, and continued support!

    – The Seals at Applied Trust

    (photo courtesy hfb under the CC)

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 19Jun

    Here at Applied Trust, we’re often asked tricky IT questions – sometimes, we have answers that might be interesting to a larger audience.  The “Dear Ned” podcast is our chance to share these IT infrastructure questions and answers.  Larry Nelson from w3w3.com will be interviewing us for regular episodes throughout 2009.

    Our first two “Dear Ned” episodes are already on-line and accessible over at w3w3.com!  The first gives an introduction to the series and a discussion of the Conficker worm.  The second is a followup to an earlier blog post, and addresses the question “I saw your blog recommending setting data center thermostats to 75°. Do you really do that? And if so, how’s that working out?”.

    Do you have a tricky IT question?  Submit it here and it may be the next Dear Ned topic!

    A special thanks to our friend Don Wrege for writing and recording our truly wonderful Dear Ned jingle!

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 03Jan
    Author: trent Categories: Infrastructure, Ramblings Comments: 5

    It’s that time again — the blogosphere is chock full of predictions for 2009 on a variety of topics, including the IT Infrastructure space.  What’s on a bunch of these lists (like Security to the Core, and TaoSecurity)?  IPv6!  Quick, run and hide in the cellar!  IPv6 is right around the corner!!!

    IPv6 in 2009?  Of all the things that might happen in the coming year, I’m fairly certain that’s not one of them.  This isn’t my first rodeo; I’ve been talking to folks publicly about IPv6 deployment scenarios at least since 1997.

    It’s true that folks are carefully tracking IPv4 allocation exhaustion.   However, when that counter runs down to zero, it’s very unlikely that suddenly IT folks in the US are going to dedicate their lives to moving to IPv6 post haste (or really, at any significant rate whatsoever).  As of October 2008, less than 0.3% of world-wide Internet clients are using IPv6.  With this abysmal adoption rate, there are lots of options at the IPv4 allocation exhaustion point that are going to be much more attractive and cost effective compared with turning the whole community on its head and moving to IPv6.  Especially in a “down economy”, organizations are not going to have the discretionary capital to purchase the necessary infrastructure equipment to make this painful  transition, not to mention the folks to learn about/implement/operate said gear.  (Additionally, for the moment, I’m ignoring the many technical and security hurdles that would also come with such a change).

    So, what happens when the clock runs out?

    Read more »

    Tags: , , ,
  • 12Nov
    Author: ben Categories: Infrastructure Comments: 0

    I occasionally need to pull mailbox data in PST format from Exchange, sometimes for archival, other times for legal review, or perhaps for some other reason altogether. This process has changed to use Export/Import with Exchange 2007, removing the 2GB file size limit and including a slew of other features, but some of us still need or prefer to use the handy exmerge tool.

    Luckily, it’s still possible to use exmerge if you keep a few considerations in mind.

    First, you must have at least “View-Only Administrator” privileges in the 2007 environment. To do this, open an Exchange command shell, and run:

    Add-ExchangeAdministrator -Identity '<your domain>.local/Users/ExMerge' -Role 'ViewOnlyAdmin'

    You’ll also need SendAs and ReceiveAs permissions on the mailbox store where the user’s mailbox lives. To find which store this is, open the Exchange Management Console and navigate to Recipient Configuration -> Mailbox. Double click the user, and on the General tab note the value of the “Mailbox database” line. Then run:

    Get-MailboxDatabase -identity "<YourServer>\<Value from Mailbox database>" | Add-ADPermission -user "<YourDomain>\<Your AD Account>" -ExtendedRights Receive-As, Send-As

    Finally, and this one got me for a while, you may have problems if the user is hidden from Exchange address lists. You can check this in the user properties on the General tab. Make sure “Hide from Exchange Address lists” is not checked.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 06Nov
    Author: ned Categories: Security Comments: 0

    It’s kooky that some organizations are still using FTP for exchanging sensitive files.  Almost every security standard (and plain common sense) requires using encrypted data transfer, and with a great free solution in OpenSSH and WinSCP, there really is no excuse for FTP.

    This solution provides the following important security features:

    • Strong user authentication with DSA keys (almost two-factor authentication)
    • Complete segregation between users (using a chrooted jail)
    • Detailed activity logging
    • Uses time and industry-tested open source OpenSSH server software
    • Familiar “drag-n-drop” user interface thanks to WinSCP

    Read on for four easy steps to make it happen:
    Read more »

  • 02Nov
    Author: trent Categories: IT Management, Security Comments: 1

    Today, November 2, 2008, is the 20th anniversary of “Black Thursday” – a significant, defining moment in Internet and information security history.  On this day in 1988, the Robert Morris Jr.  worm was unleashed on the Internet.  Sometimes called the Great Worm, this was the first time that the world had proof of what we all knew to be true: significant damage could occur if a malicious party exploited known vulnerabilities across the network en masse.  As silly as it sounds now, prior to that date we always talked about how a worm “could” happen; now we fret about “when.”

    RTM’s worm brought significant change to the Internet world.  The damage it caused (possibly upwards of $100M) and media attention it received ultimately provided the foundation for much of what we know as modern-day, non-military Information Security.  For the first time ever, the Internet became well-known to the mainstream media.  DARPA provided funds to form CERT at Carnegie Mellon, which also directly or indirectly resulted in most clueful organizations establishing their own information security or security incident response teams. Many of the security standards we take for granted are based on early work done at CERT.  I’ll save the debate about whether the worm was ultimately good or bad for our community as a whole for some later post.

    Personally, this date also marks the start of my career in Information Security.  I was in the Computer Science system support group at the University of Colorado at the time, and vividly remember sleeping on my office floor for the last half of that week.  Our primary production systems – mostly VAX 11/780’s, 11/750’s, and Sun 3’s – were all infected.  Lacking any formal incident coordination and communication  infrastructure, we reached out to our friends at UC Berkeley and the University of Utah to collaborate on how to contain and mitigate the situation.  We provided data to the teams working on dissecting the worm, some of which ultimately led to Donn Seeley’s USENIX paper which is still regarded as the most complete and accurate technical analysis.

    It’s great to reminisce about history, but where are we 20 years later?  Although I’m not currently planning on sleeping on my office floor tonight, ironically today I am again worried about the potential for a worm to spread uncontrolled due to lack of patching.  Specifically, the Microsoft MS08-067 vulnerability that was released out-of-cycle 11 days ago represents a significant threat to almost every Windows system out there.  In the last week, I’ve heard all the same arguments against patching that we did 20 years ago — too much effort, too much risk to availability, not enough threat.

    It’s true that overall we have better mitigating controls in place than we did 20 years ago — most organizations have a firewall, virus protection, an incident response plan, and maybe even IDS/IPS.  The bottom line, though, is that none of this eliminates the need for patching serious vulnerabilities.  As an industry, we MUST patch known serious vulnerabilities, and it takes the same amount of time to patch them now as it does later.  It’s just a question of whether you want to suffer the pain and embarassment of looking like a fool in between doing it “now” vs. “later.”

    I admit to being an “old dog” (and certainly, this particular anniversary rubs that in) but personally, I’d rather make the effort to apply a patch than look like a fool.  Any day.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 31Oct
    Author: ned Categories: Green IT Comments: 0

    At Applied Trust, we’re often known as the company with the cool outdoorsy schwag. Has your Applied Trust schwag traveled to exciting and unique places with you, or does it otherwise have an interesting story to tell? If so, we’d love to hear about it!

    Send your “schwag brag” ideas (with photos) to schwagbrag@atrust.com. Whoever submits the most outrageous story and photo between now and December 31, 2008 wins a 3-day trip for two to beautiful Cozumel, Mexico!

    We’ve already received some great submissions – hurry up and get yours in the door!

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 20Oct
    Author: admin Categories: Security Comments: 13

    As I began down the dismal path of studying for my (ISC)² SSCP certification I ran across an interesting concept in my study guide called “keystroke dynamics.”  Basically it’s a form of 2-factor authentication that allows users to authenticate not only by password but also by the way in which they type their password.

    What’s interesting is it is one of the only forms of biometric authentication that can be implemented at little cost with currently available technology.  Of course there are cons to KSD (don’t get arthritis!) but if you give users the option to authenticate by KSD OR via a series of the usual what’s-you-mother’s-maiden-name questions, I believe this could be practically implemented.

    KSD relies on analyzing dwell time (the time a user keeps a key depressed) and flight time (time between typing one character and the next).  This data is recorded and then transmitted along with your password.  If there is too much delay between the valid dwell time or flight time access is denied.

    I thought I’d attempt a web implementation using PHP and JavaScript.  You can see the results of this endeavor by playing with the demo below.  It captures dwell and flight differences in milliseconds and if you are within the valid omega for each and posses the valid password you will be granted access.

    I was playing with the mathematics behind this the other day and it seems like this would make it exponentially harder for an attacker to brute force a user’s password.  If we take the dwell and flight omegas I use in the demo below (120ms and 100ms respectively) and let’s suppose from person to person dwell times deviate approximately 400ms and flight times can deviate 1000ms we can calculate how many more combination are possible in a standard 8 character password:

    (400ms / 120ms) * (1000ms/100ms) = ~33 unique ways you can type one character

    (400ms / 120ms)^8 * (1000ms/10)^7 = ~152,415,790,276 ways to type an eight character password

    This means, even if an attacker knew your password (ie. saw you type it or by means of keylogger) he would then in theory have to try all the 152 billion possible ways to type the password.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]
  • 10Oct
    Author: ben Categories: IT Management, Security Comments: 2


    You wouldn’t know it by the number of vendors and products on the market, but event management and log correlation is really, really hard. Despite the excellent work by folks like Anton Chuvakin, enlisting any support at all for log centralization, monitoring, auditing, and intrusion detection can be like pulling teeth.

    Indeed, who can blame leadership for hating event management?

    • It’s extremely time intensive to do well
    • It’s expensive, even if you go with an open source platform
    • Maintenance is a lot of work, requiring lots of hardware (particularly storage) and expertise
    • It’s woefully inaccurate, and stunningly misleading in some cases

    My biggest frustration? The lack of a standard format. Sure, the logging experts will point out that acronym-filled standards like the CEF (Common Event Format) or the WTEF (WebTrends Enhanced Format) are out there, but nobody uses them. Thus, it’s left as an exercise to the leader to normalize logs in to a universal format.

    Moving this in to the real world for a moment, let’s ponder the challenges that this brings to an enterprise of, say, 5,000 employees. This enterprise likely has a lot of Windows servers running Windows-y applications like Active Directory, Sharepoint, and Exchange. Said organize probably has a few Unix or Linux systems around, spewing out syslog data. Lots of network devices are around generating firewall rule matches and error data, and there’s probably several proprietary applications logging directly to a localized database.

    A “real” event correlation system would need to capture, centralize, normalize, audit, correlate, and alert on ALL of this data. It will require lots of maintenance as upgrades occur and storage requirements go. And don’t depend too much on the vendor – they’re probably too busy forgetting to install patches to worry about “centralized what”?

    But guess what? It doesn’t matter – you have to do it[PDF].

    That isn’t to say that it’s hopeless. The point is to find the strategy that works best for your organization. Maybe you just capture the critical event logs from Windows systems. Or perhaps you have a world class IDS with custom rules that capture log in events. Whatever the case, don’t try to bite off more than you can chew, or it’s bound to fail in the end.

    [Slashdot] [Digg] [Reddit] [del.icio.us] [Technorati] [StumbleUpon]