The Security Skeptic

This is the transcript of a recent podcast I produced for TechTarget.

Authentication and authorization are the two most fundamental and commonly employed attributes of security. They sound alike, and their definitions are often confused, so let me begin by offering mine:

• Authentication is the means by which a person proves he is who he claims to be in a non-refutable manner. Authentication is also a means whereby a computer system proves it is the originator of a packet, and how an application such as a web server proves it is the agent for an e-merchant's online credit card transaction.
• Authorization is the process of determining whether an identity is entitled or allowed access to a resource or asset. Authorization typically assumes that an identity has been authenticated. An identity that is allowed access is trusted and granted access permissions, in accordance with defined policy.

Most organizations use one or more authentication methods, and extend these to branch office users. Fewer organizations devote as much attention to authorization. Commonly, authenticated users at branch offices have access to individual and group accounts on local servers as well as intranet servers hosted at HQ, but unrestricted access to the web and collaborative applications like IMs and VoIP.

Assuming yours is an organization whose branch offices have an authentication strategy in place, I recommend that you add a security A. Revisit your authorization policy for branch offices. Consider implementing egress traffic filtering. Rather than allowing access to ANY external service, begin with a DENY ALL rule, and allow access the set of applications you determine are business-appropriate.

So far, we've looked at two security attributes, and both begin with the letter A. Curiously, or perhaps intentionally, many other security attributes begin with the letter A: Accounting, Accuracy, Authenticity, Availability.

Not remarkably, security professionals took advantage of this happy circumstance and developed analog to explain the fundamentals of security. An early popular analog likened the essential attributes of security to a three-legged stool to illustrate why security, like a stool, needs more than two legs to stand on its own. Authentication server vendors, especially those who supported what is known as the RADIUS authentication protocol chose to add accounting for the third leg. They coined the term Triple A to kindle interest among Service Providers who were exploring alternatives to flat monthly rate Internet access.

Today, some security professionals feel that accounting was the best choice to complement authentication and authorization as a third leg and replace accounting with the more general (and in my opinion) practical choice of auditing, which is the process of monitoring and recording networking and security-related events for subsequent correlation and analysis.

Auditing is commonly implemented using event logging and most server, storage, networking and security systems you would consider using in a branch office can log events. I encourage you to add a third leg to your security stool. Assess the extent to which logging is enabled at your branch offices. Develop a strategy for monitoring branch office activities more aggressively and for securely transmitting logs to a central repository where they can be analyzed in the aggregate by the expert staff you are more likely to have at your main office NOC and data centers than branch offices.

Are three legs sufficient? Anyone who's used a three-legged camper's stool on uneven or soft ground will attest that three legged stools are not the steadiest seat one might design.

Four legs results in a sturdier seat. For many security professionals, the fourth leg of choice is Authenticity or its security synonym, Accuracy. Authenticity is a process by which the integrity of data and its origin are verified. Authenticity assures the recipient of data that the data he received are an exact copy of the data that were transmitted, and that the data were indeed produced by the sender. You can implement this security A in many ways, and incrementally. Consider whether integrity protection measures would be appropriate for the data that is likely to reside, be stored at, or communicated to and from branch offices. For example, it might be useful to put anti-tampering measures on servers to protect against unauthorized or unintentional modification of critical system and configuration files. If your business routinely exchanges sensitive information using internal mail and document delivery systems, consider whether employees should hash and sign such documents.

Four legs makes for a sturdy stool. But recently, security professionals are exploring ways to make the stool even sturdier if somewhat unusual in appearance.

Historically, authentication has been considered the enabler of all security services. Let's look at some examples where having verified that a person is who he claims to be isn't enough.

• Mary proves her identity to an air transportation security inspector using her government-issued passport. Knowing that Mary is indeed Mary doesn't assure us that she's not concealing a weapon.
• John proves his identity to a US Customs and Immigration officer using his new Canadian high-security driver's license. Knowing that John is who he claims to be doesn't tell us whether he's carrying a communicable disease.
• Beth is on her way to a confidential board meeting where her company's earnings will be reviewed prior to public disclosure of its annual report. She proves her identity to the security guard at her employer's office using her company-issued ID. Knowing that Beth is who she claims to be doesn't tell us whether an industrial spy's planted a listening device on her clothing.

Suppose Mary, John and Beth are not people but computers trying to connect to networks. Mary's concealing a root kit. John's infected with a virus. Beth's hosting a keylogger. Just as in our real world examples, authentication alone doesn't help us assert the trustworthiness of the endpoint device from which a user will authenticate and subsequently access data.

Admission control adds a desperately needed leg to the security stool. It's conceptually simple. When a device attempts to connect to a network, we examine that device to verify that it is free of malicious code before we accept a single keystroke from a user at that device. We can verify that all security measures - firewall, antivirus, antispyware, host IDS - are have all the current patches, malware and intrusion signatures, are properly configured and are operating as anticipated. If an endpoint fails to meet these criteria, we can block admission, or quarantine the endpoint to a location on our network where the user can access the resources required to bring the endpoint into compliance.

Many organizations have successfully implemented these five As throughout their main offices and campuses. Organizations who've completed this phase of deployment are now actively planning and in some cases deploying additional security As to branch offices. The blueprint for branch office deployment will vary across organizations.

Organizations that run their networks in a hub and spoke arrangement are best positioned to add As to improve branch office security. These organizations can leverage admission control and authentication services already deployed at main offices so that all devices are screened for admission, all users are authenticated, data access controls are imposed uniformly, all network and security events are audited and all copies of data are readily authenticated.

Organizations that allow branches to operate more autonomously, or that must contend with business variables - mergers and acquisitions for example - may have to choose a different path. Fortunately, admission control is available in many point products and can be used in complement with branch-in-a-box solutions to add this fifth and valuable leg to the stool. And while your organization is implementing admission control, it can revisit some of the other security As as well.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID620 by Dave Piscitello  

It's too early to tell but SPIT - spam for IP Telephony - may not be as profitable or as much of a pandemic as spam. Before you get too excited, let me begin by stating that such a positive outcome would not be the result of carefully conceived and thoughtfully deployed security features designed to make VoIP less susceptible to spoofing of the sender (caller) than email. These may come eventually, but for now it's often as simple to spoof a calling party in VoIP as it is to spoof the sender of an email message.

However, it's arguably harder to create a payload that can prove as effective in deception as the successful email messages. SPITers may be able to spoof my SIP calling address (phone number) as easily as spammers spoof my dave [at] corecom [dot] com address but they may not be able to impersonate my voice as easily as they might compose a text message that appears to have been composed by me.

Of course, the majority of spam that is delivered purporting to have originated from my email address isn't delivered to folks who can readily distinguish my voice from that of an imposter. Even in these cases, deception using voice messages may not be as easy as it is with text and images. I'll speculate that the majority of voice calls end up being saved to voice mail, since called parties are always either busy or away from their phone (in large part because they are reading email and filtering spam, but I digress). This has several consequences. It may be possible to develop countermeasures that, like anti-spam, can determine if the voice message (payload) is SPIT and remove them. Even if SPIT calls are completed, many VoIP users have extensive prior experience with telemarketing and other nuisance or unsolicited callers (BTW, why can't we add "anyone calling from any political party" to the Do Not Call list?). Repetition is the key to learning, and a fair number of phone users recognize an unsolicited call within seconds if not following the first utterances and know to hang up. But is this enough? Well, probably not.

A broader threat SPIT poses is probably not from impersonation of personal calls (i.e., from individuals) but of calls placed by automated voice agents, the kind that call you with a billing inquiry or service order and ask *you* to verify your identity by entering birth date, account number, social security number, or other information that can be used to steal an identity. Only a small percentage of data users have dealt with "call back" arrangements to verify the origin of a modem call, and fewer still have ever used a voice-based application that is designed in this manner. Unless VoIP can preserve the validity of Caller ID, this threat can undermine consumer confidence not only in SIP-based voice applications but PSTN-based applications as well, since these may be indistinguishable.

sigh...

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID619 by Dave Piscitello  

Beyond studying web logs for security purposes, my web log analysis needs are modest. I want to periodically look at hits, determine page and hence topic popularity, and identify errors. At-a-glance graphics are nice but not entirely necessary. I want a simple UI, the ability to upload a zip file of log files and feed these into analysis software I'm running on a system other than my web server. I'm certain most web log analysis software vendors shudder to think of a marketplace full of folks like me.

I recently tried and really like WebExpert Log Analyzer Lite Version. It's free. The UI is intuitive and with only four buttons to choose, about as basic as you can ask. You create or open an existing profile, a configuration file for a web site, you save, and you click "Analyze". WebExpert analyzes an individual or zip archive full of Apache or IIS logs, launches your default browser, and displays a set of reports and graphics that you can navigate using a Windows Explorer style interface.

Many companies frustrate would-be users by crippling free versions but the folks at WebLog Expert have done a nice jump of creating a useful subset for the Lite Version. The Lite Version provides a summary report, daily and hourly reports, access reports (page, file, image, directory and entry page), a visitor and browser report, and several referrer reports (sites, URLs, search engines and phrases). It also summarizes errors by error code. A Standard and Profession version offer much more, at relatively modest prices, affording me an upgrade path should I ever need more than the features in the Lite edition (compare the versions here).

You won't find this software enormously useful for studying web application and server security issues, but it will serve a small shop well as a basic analysis and *first look* tool. Works under Windows 95/98/Me/NT/2000/XP/2003/Vista operating systems.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID618 by Dave Piscitello  

Many networking and security practitioners are familiar with the triple A - authentication, authorization, and accounting. I've mentioned in previous blogs that we actually need more As than three. I recently recorded a podcast for searchNetworking.com where I examine how the popular three-legged stool of security keeps growing legs.

.

This podcast is also part of the Securing the Branch Office series, available at searchNetworking.com.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID617 by Dave Piscitello  

Broadband local access provides branch offices with more affordable bandwidth today than many organizations' main offices had when they first became Internet-enabled. Bandwidth is not the only resource that's become abundantly available to branch offices. The cost of server hardware has tumbled over the past five years. Remarkably, a platform suitable for Windows 2003 or Linux server costs less than an extreme gaming computer. Many organizations see these as economic windfalls that allow them to host business-critical applications in branch offices. But while advances in telecom and technology create opportunities to enhance business productivity, they expose organizations to new threats.

This Tech Tip explains why branch offices have become green fields of opportunity for attackers, and recommends 10 security measures to reduce many threats. This is part of a series on Securing the Branch Office, available at searchNetworking.com.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID616 by Dave Piscitello  

What for, beyond accepting LinkedIn invitations?

Someone please tell me if LinkedIn is anything other than a MySpace for professionals. Or do C*Os get the same adolescent rush that teens do when they have the largest number of friends? Tell me, please!

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID615 by Dave Piscitello  

In an opening keynote for a seminar series - The Pros and Cons of Integrating Security into Your Networks - my colleague and friend Joel Snyder compares the task of designing networks to designing a plumbing system for a home or office. As I listened to Joel speak, I realized the analogy is very effective in illustrating just how challenging both tasks can be when users, usage, and measures to prevent abuse exceed the original design objectives.

As security and network architects, we are expected to maintain a plumbing system that is highly available and performs well. Problems arise when we cannot or fail to anticipate future capacity and do not properly assess risks. Both networking or plumbing systems that we design to support 100 can unexpectedly be called upon to accommodate several hundreds of users. Consider the collateral impact in the case of plumbing. An expansion of this scale not only affects current plumbing but other systems in a building as well, possibly extending to structural, electrical, alarm and HVAC systems. The same is often true for networking and is especially true in the case of power and HVAC.

Plumbing and networking maintenance must consider the problems associated with poorly configured systems. Hot water heaters left set to certain manufacturers' defaults can cause severe burns on young children, as can hot water pipes connected to cold water handles on faucets. Failure to properly ventilate toilets has both unpleasant and potentially hazardous consequences.

Both networking and plumbing also must contend with abuse. Network and security admins must provide detection and countermeasures for denial of service attacks, and so must plumbers. DoS threats to plumbing systems include overzealous users of toilet paper, toddlers who fill tubs until they overflow, and teens who block faucets with gum and drop M-80s into commodes. Networking plumbers must worry about information leaks. Plumbers worry about leaks, both ingress and egress :-)

We could extend the analogue considerably beyond these few comparisons. It's a useful one, so *use* it.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID614 by Dave Piscitello  

A recent thread on the pen-test@securityfocus.com mail list asked whether firewall rules should drop or reject traffic that doesn't conform to the security policy. A firewall that rejects inbound traffic will either respond with an appropriately flagged TCP segment or return an ICMP response packet to the traffic originator (the ICMP packet contains an error notification that was originally intended to be used for diagnostic purposes). The responses a host would typically generate are as follows:

SYN/ACK if port open
RST/ACK if port closed
ICMP message type 3, code 1 (Destination host is unreachable) if targeted host is down
ICMP message type 3, code 0 (Destination network is unreachable) if targeted subnet is down
ICMP message type 11, code 0 (Timeout during transit) if destination cannot be reached within the specified TTL

A firewall that drops or silently discards inbound traffic is operating in what many call stealth mode and does not return any packet whatsoever. In theory, by not responding, the administrator prevents a would-be attacker from gathering information from the firewall.

In practice, operating systems of nearly every networked device can be distinguished from each other by the way (TCP) response traffic elicited from open ports is composed: this is called OS fingerprinting. Moreover, a security policy can be deduced by enumerating listening/responding ports, so security by obscurity buys you very little. However, some security practitioners argue that operational considerations may influence whether you reject or drop traffic, and if your firewall permits, you may wish to implement a different strategy on your trusted interfaces and public-facing (external) interfaces. For example, some practitioners suggest that responding explicitly using reject messages can be a useful strategy on trusted interfaces, to reduce delays associated with timeouts: if a port or destination is blocked, the client attempting to connect to that destination receives an error notification on the first attempt and no retries are attempted. On external interfaces, the reject strategy will cause the firewall to return a message to the source address in the IP header encoded in the packet that violated the security policy. This may be a spoofed address, and an attacker can use your firewall in a redirection/nuisance attack by spoofing the source IP address to point to a targeted 3^rd party.

One pen-tester made an interesting observation with respect to rejecting traffic on external interfaces and the potential that responses might abet a DOS attack.

...the chances are your network is going to expose at least one TCP port to the outside world, for instance. If you do, then an attacker can use you for reflected TCP handshake amplification on that port. You won't be able to do much to stop it, in all likelihood, and it doesn't matter if all of your blocked ports send out one [reject message]. The attacker won't bother using it, since he gets better amplification on the open port...My research was specifically focused on information leakage through TCP port scanning. After modeling the various scenarios (SYN stealth scanning, spoofed SYNs, spoofed SYNs through an idle scan, etc), I found that the best strategy for the defender is to always return a RST/AK on blocked ports.

The poster explains that a strategy limiting reject messages per IP address to one is a form of what is called tarpitting. Tarpitting is a strategy often used by email system admins to discourage spam. The email admin will cause an SMTP session to be paused after a permitted number of RCTPs is processed which makes his server more available to legitimate users and less attractive to a spammer (a delay of seconds imposed across millions of email messages can extend the spam delivery timeframe from minutes to months). This strategy does not prevent scanning but it does prevent your firewall from being the reflector of large numbers of TCP segments to a targeted third party machine (the machine that uses the IP address that was the source address in the instigating packet). If you explicitly reject every packet you receive from a single IP address, you generate lots of redirected packets. If you only send one per IP, you eliminate this amplification factor.

I thought this was an interesting thread and have attempted to consolidate many of the useful comments it into a single article. I take no credit for the comments and offer kudos to the folks who participated.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID613 by Dave Piscitello  

In BlogID608 I mentioned IT Security's 103 Free Security Applications, and promised to test and review some of these. As promised...

Spyware Terminator is a very nice and complete antimalware package. At first, I was hesitant to even install this package because I recalled a similarly named scamware product, Spyware X-Terminator. After poking around other antispyware and malware info-sites, I sorted through the conflicting opinions and misinformation before concluding these were indeed different packages.

Spyware Terminator provides real-time protection, spyware removal and quarantine. Spyware Terminator provides two levels of scanning: full and quick, and the latter lived up to its name by completing a scan in under 1 minute on three different Windows machines. Spyware Terminator provides a rudimentary host intrusion prevention system by building a list of installed, spyware-free programs and only allowing these and other applications identified by you or the developers as known-to-be-safe applications to execute.

The installer provides an integrated version of the popular open source-based WinClamAV antivirus software. WinClamAV is based on the same antivirus engine as the version I'm using on my MacBook and I'm just as comfortable installing and using it on a Windows machine. On my test systems, I ran Spyware Terminator without interference or conflict with AVG 7.5 Professional antivirus (I used this instead of WinClamAV on one PC) and other antispyware software (SpywareGuard, Spybot Search and Destroy). Automatic updates, beginner/advanced/expert configurations and a file analysis utility (to test if a file is suspect-ware) make this a useful antispyware package. A commercial version is available for organizations who want to centrally administer antispyware measures on all machines connected to a network.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID612 by Dave Piscitello  

Colleague David Strom discusses waning attention spans in his 4 May 2007 Web Informant. In the article, David explains how his attention span is getting shorter and shorter, and how he and other noteworthies including Rupert Murdock, rarely finish the long (WSJ) stories, web pages, long emails, and online articles. It's an interesting admission for an author and e-publisher, and you ought to take a look.

The subject of David's column - and in particular how online publications are responding to what they perceive as visitor/subscriber needs - is consistent with what I see and hear from tech media people all the time. Where I was once asked for articles ranging from 1200-1500 words, I'm now asked to keep an article under 800 words: 600 would be better, and 400 is ideal.

This trend is very disturbing. We appear to be devolving into a "just tell me what I need to know RIGHT NOW, how to do this RIGHT NOW, keep it brief I'm too busy to care WHY" society. Fewer and fewer IT professionals are learning architectural and other *big picture* networking and security principles, and rely instead on technology to solve the problem.

This attitude is not isolated to Internet technology; in fact it's a pandemic. Consider your automobile. Fewer of us know the basic principles of combustion engines, brake and electrical systems in our vehicles. We are increasingly dependent on technology to troubleshoot and to identify the parts list and labor when we need a repair or routine maintenance performed. We don't know more than the basics of driving and many drivers only learn the absolute basics needed to obtain a license. Think of the number of drivers who can't parallel park, or who don't know the correct way to orient the wheels of a vehicle when parked on a hill. I won't even speculate how many (US) drivers can parallel park on the left-hand (driver's) side of a one-way street. Too many licensed drivers invest time and brain cycles to become safer drivers, and it's painfully evident that PC and Internet users invest even less time learning how to be productive and safe while computing and networking.

If we only have patience and the willingness to deal with a symptomatic problem in the most mechanical, boilerplate and simplest manner, what differentiates us from robots? Asking why and taking the time to study an issue is not only becoming an endangered attitude, but it seems to be falling out of favor as well. When attendees approach me with questions after I've given a seminar, I get the distinct impression that taking the time to understand why X is a best security practices is unimportant - management barely acknowledges the need for the best practice and doesn't appear to encourage education and awareness as business productive activities.

I'm not entirely sure this is an accurate picture, but it is a really worrisome condition if it is.

Archived at http://www.securityskeptic.com/arc20070501.htm#BlogID611 by Dave Piscitello