The Security Skeptic

I met a field officer from the US Customs Department while speaking in Washington,DC. He showed me an Ironkey, a hardened and secure USB drive. Some of the Ironkey features that impress me include:

• Tamper resistant and waterproof casing. The device is "potted", i.e., the crypto chip and memory are encased in material that protectsthe electronics from water damage. At the encouragement of the USCD officer, I put mine in my jeans pocket and tossed it in the washer:-) and it works fine.
• Always-on AES encryption. The encryption keys are generated by the embedded crypto chip using a FIPS 140-2 compliant True Random Number Generator.
• Password protection, online password recovery and escrow. You can escrow your device password at a secure site. Access to the secure site requires you to to answer multiple authentication challenges. Authentication is multi-factor as well: you cannot complete authentication if your Ironkey is not connected to the PC when you attempt to log in.
• Antitampering measures. 10 incorrect passwords and the data are erased from the device or if someone attempts to remove the crypto or memory chip from the casing.
• On board password manager: you can encrypt and store all your passwords on the device.
• Secure applications. You can surf from a hardened Firefox browser that can be launched from the device, or you can use Ironkey's encrypted and anonymous proxy service.
• Secure (encrypted) backup from the device to an encrypted file on a PC.

Ironkey comes in personal and enterprise flavors and sizes. The devices are generally about 2-3 times the cost of an unsecured USB drive having the same storage capacity. This is a small price to pay for a more secure portable media solution.

The configuration software is currently for Windows PC only, but once configured, the device can be used on Mac OSX and Linux systems. I've asked about MacOS support for the config application and the company has plans to deliver in 4Q08.

Visit www.ironkey.com, watch the demo, read more about the device, and consider test driving one for yourself or your organization.

Archived at http://www.securityskeptic.com/arc20080501.htm#BlogID689 by Dave Piscitello  

A recent article in ISSA Journal describes risk-based authentication, a technique that adjusts the credentials an individual must provide to verify his identity based on the threat that the party attempting to authenticate is an imposter. The author describes many bases on which the risk of impersonation is gauged, including the weekday, time and location from which the party is authenticating, whether the party frequently connects from this location, the endpoint device the party uses to connect (i.e., a computer that the user has registered with the authenticator), etc. Anomalies in any of these and other criteria cause the authenticator to add challenges to the baseline authentication method. The added challenges are designed to increase confidence that the party is whom he claims to be, i.e., personal questions that only the authorized party in theory can answer. In principle, the more this session attempt deviates from the user's norm, the higher the risk, and hence the user must provide greater reassurance to the authenticator. A breaking point can be implemented: too many anomalies and the party will be blocked from connecting.

I like the concept, but it's too narrow. In addition to authentication, I'd like to see authorization be risk-based as well. There are many circumstances where the risk of disclosure, potential for coercion, etc. might be sufficiently high to warrant an "access denied from your location, at this time" action. Prior to authentication, the risk of accessing sensitive information from the endpoint device used should play a factor; for example, while an employee might be permitted access to email from a public computer, it may be appropriate to deny access to a database from that computer.

I described a "continuum of trust" at several seminars that complements this thinking. The actions involved in asserting trust (assessing risk) are illustrated below:

Using the risk-based strategy, begin by determining the risk associated with the device, location, day and time, etc. If the risk is acceptable, allow the user to authenticate, using the risk analysis described earlier. Continue by enforcing access controls on data requested, again according to risk.

The last component, exit control, is not risk assessment, but risk mitigation. Make certain that nothing that would disclose the user's credentials, activities, and of course the data accessed remain on the endpoint device before closing the session.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID685 by Dave Piscitello  

While reviewing my web logs today, two patterns emerged: the incidence of referrer spam in my logs is increasing and I'm getting a fair number of visitors from the University of California, San Francisco School of Pharmacy. I'm not sure I want to invest a lot of time thwarting lame-ohs from spamming my logs since they'll only be replaced by some other lame-ohs. My curiosity, however, did lead me to track back to the referrer site at UCSF.

The School of Pharmacy devotes several pages to educating users on how to choose a password. This tutorial includes a page that provides examples of bad passwords, and a page I host at The Security Skeptic is linked as an example resource containing a High Probability Password List.

Kudos to UCSF SoP for the effort. I'm always happy to see a resource I post put to good use:-)

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID653 by Dave Piscitello  

You don't have to invest in expensive automated tools to perform network security assessments. In this searchSecurity.com Tech Tip, l explain how you can use data from freely available tools to produce a comprehensive view of network security. This tipis part of the Advanced Network Workshops: Integrating Networking and Security series, available at searchNetworking.com.

Archived at http://www.securityskeptic.com/arc20070801.htm#BlogID644 by Dave Piscitello  

The line between networking and security products grows fainter each Moore's cycle, and it seems there is no end in sight. In this searchSecurity podcast, I discuss what to expect in the next 12 to 18 months and how IT professionals specializing in networking or security should prepare themselves to integrate and manage embedded network security devices.

.

This podcast is also part of the Advanced Network Workshops: Integrating Networking and Security series, available at searchNetworking.com.

Archived at http://www.securityskeptic.com/arc20070801.htm#BlogID643 by Dave Piscitello  

Bruce Schneier's 15 August 2007 issue of Cryptogram offers a very good summary and analysis of the problems plaguing electronic voting machines. This is good reading! To encourage you to read the column, here are a few telling comments:

"Serious flaws were discovered in all machines and, as a result, the machines were all decertified for use in California elections."

"The fact that major security vulnerabilities were found in all machines is a testament to how poorly they were designed"

and the real kicker...

"California Secretary of State Debra Bowen has conditionally recertified the machines for use, as long as the makers fix the discovered vulnerabilities and adhere to a lengthy list of security requirements designed to limit future security breaches and failures."

Bruce does a nice job debunking the propositions that "If there are no known vulnerabilities, the system must be secure." and "If there is a vulnerability, then once it's fixed, the system is again secure." Nicely done.

Archived at http://www.securityskeptic.com/arc20070801.htm#BlogID639 by Dave Piscitello  

I coughed up five dollars, purchased a PayPal Security Key™ and now use it for my eBay and PayPal transactions. I'm very curious to see how this added security measure by a major online merchant with a diverse customer base will play out. A considerable number of PayPal and eBay's customers are non-technical, so what percentage of PayPal users will adopt Security Key™? How well has PayPal anticipated the helpdesk and loss-replacement costs? Will the *realized* reduction in fraudulent bids, sales, impersonation, identity thefts, and online payments justify the investment?

Whether Security Key™ succeeds or fails, I believe this initiative has the potential to be a landmark event. Multi-factor authentication is decades-old technology, yet its penetration remains small relative to password-only authentication. Imagine if, one year hence, the PayPal/eBay experiment has demonstrated that deployment can scale to a user population that's at least an order of magnitude greater than the enterprises that commonly adopt tokens, that users finally acknowledge that stronger authentication than passwords is beneficial and will *voluntarily* adopt and comply with multi-factor authentication, and that the companies are able to report a marked reduction in impersonation-based attacks and a corresponding reduction in losses associated with such attacks. Such results would be hard to ignore, and perhaps, finally, we'd seen the beginning of the end of password-based authentication.

"To sleep, perchance to dream- ay, there's the rub." - Hamlet (III, i, 65-68)

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID633 by Dave Piscitello  

In the February 2003 issue of BCR, I co-authored an article entitled The Sad and Increasingly Deplorable State of Internet Security where we claimed that, "overall, Internet security really is in horrible shape." We were convinced by computer crime statistics, incident reports and our collective experience that the security technology deployed to date had not proven effective. In fact, incident frequency and cost were increasing at an alarming rate, despite the fact that most organizations were claiming to have deployed state-of-theart security defenses.We predicted that security would worsen before it improved.

Four years later, BCR invited us to comment on the state of Internet security. Read Sad and Deplorable State of Internet Security, Revisited to learn if things have changed for the better or worse.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID628 by Dave Piscitello  

While combing my local archives, I located two additional articles I published at SecurityPipeline:

• Add "Protect Your Domain Name" to your security check list

• Security Freeware: More or Less than you paid for?.

  I'm confident these are the versions originally published.

  Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID627 by Dave Piscitello  

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  

If you develop a rash or an insect bites you, and the site begins to itch, you'll most likely scratch it. If the itch is relentless, you will exercise one of several choices. You may visit dermatologists, allergists, and internists to diagnose whether the itch is symptomatic of a skin disease, allergy, or more serious disorder. Once diagnosed, the health care give will recommend that you mitigate the problem by using antibiotics or steriods, or by introducing changes in your dietary habits, or by some other treatments.

This path is often expensive and time-consuming. Many of us often choose to apply non-prescription topical creams and oral antihistamines that offer temporary relief and hope the itch goes away.

Internet security is largely practiced by applying topical creams, swallowing antihistamines and using steriods. We are too busy and think our budgets are better spent elsewhere than security so we apply inexpensive, quick fixes and pray. Here's a popular example. We'll interpose a $300 firewall appliance between a small office server and our broadband access but will configure it to allow ANY traffic outbound from ANY address behind that firewall including servers. We often don't think overly carefully of the implications of that configuration.

Many will argue that this course provides many organizations and individuals temporary and tolerable relief in "surface symptom" areas like spam and malware. I'd be curious to compare the total cost of deploying antispam measures over the past decade against the cost of deploying email system that allowed us to reject bogus mail senders. 500+ weeks' worth of cortisone cream and Benedryl, folks!

Symptomatic treatment versus early diagnosis and mitigation of the root cause. Are you happy with temporary relief?

Archived at http://www.securityskeptic.com/arc20070401.htm#BlogID610 by Dave Piscitello  

Business Communications Review has invited Dr. Stephen Kent and I to publish an article that revisits the topics we discussed in our 2003 article, The Sad and Increasingly Deplorable State of Internet Security. As Stephen and I prepare this article for BCR, I thought you might want to read the original article. BCR has graciously sent me a copy to publish here (pdf).

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID595 by Dave Piscitello  

Having attracted broad media attention in November, one would expect that the egos of the <ahem>researchers</ahem> responsible for the Month of Kernel Bugs, if not sated, might at least remain bloated for more than a month. No such luck. These same crackers intend to disclose a Mac OS X bug daily during the month of January 2007.

The crackers conducting the Month of Apple Bugs project promise a steady stream of zero-day disclosures that will expose the over-hyped Mac OS X Security as a house of cards, humble Apple, and of course, focus attention to the astonishing prowess of the the Lamo/Mitnik de jour.

Zero-day disclosures are self-absorbed, self-serving, narcissistic acts. They benefit no one except the crackers who disclose the vulnerability. You are sad, strange little men, and you have my pity.

How should Mac OS X users prepare for MOAB? Tighten up your OS X Security a bit. Begin by visiting Mac Geekery and review the ten security measures Adam Knight prescribes in Basic Mac OS X Security. Once you are satisfied that you've raised your Mac's defenses to this baseline, and if you are serious, consider disabling Unneeded Services. Then bookmark MacGeekery.com and visit this and other security sites regularly.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID578 by Dave Piscitello  

Listening to NPR today I *think* I heard someone include the November 2006 midterm elections as tops on this season's blessings list. It's certainly on my list, but perhaps not at the *very* top.

I began thinking about this season's security blessings but not overly long because this should be a time of good tidings and joy:-)

Sooooo... putting on my "positive attitude" Santa hat, here's a list of what I consider security blessings for 2006:

• Firefox. OK, this is a carry-over blessing from 2005. I removed the IE icon from my PC desktop and run iexplore.exe only under duress.

• AVG version 7.5 antivirus. This was the year I finally ditched Norton AV and I haven't regretted it. AVG is gentler on my RAM and has been as effective an antivirus solution as NAV had been.

• APC UPS Backups 725. I have three now and they are as reliable as advertised.

• TRENDNet TE100-S24WS Access Point. Much less expensive than Linksys and just as security feature-full. Only a year ago I couldn't stumble any RF within 300 yards of my home; now I see 7 APs. WPA for the win.

• WatchGuard Fireware 8.x HTTP Proxy (and generally, all the proxies). I've chronicled the many features I routinely use to strip cookies and executables, scrub HTTP messages, block ads and unwanted connections. I don't know how people live without proxies. Stateful inspection may rock, but IMO you can't have rock solid perimeter security without proxies.

• IISLockdown/URLcheck. I host a very conservative web site(s) and these simple utilities plus network and http logging increase my faith in layered defense.

• MacOS X. You can't appreciate the malware "taxation without relaxation" until you use a Mac for a while. Add the cost of purchasing, installing, configuring, maintaining both XP security policy and 3^rd party security software to the extent I've become accustomed over the past 4 years on each Windows PC in your office and it's way less expensive to run a Mac shop. Call it security by obscurity if you want, but I'm not unhappy to have left the ranks of the low hanging (client) fruit.

That's a pretty short list. Hey, I promised to share only good tidings of comfort and joy.

Archived at http://www.securityskeptic.com/arc20061201.htm#BlogID576 by Dave Piscitello  

Endpoint, admission and exit control are hot topics these days. Combined, these security measures attempt to block entry to compromised and infected systems and prevent unintended disclosure of sensitive information such as user account credentials on managed end points. They also protect networks against misuse from systems users might employ that lie outside the administrative reach of an organization's IT staff, such as home and publicly accessible systems.

Justifying an investment in "prevention technology" can be a hard sell in some organizations. IT often only has speculative numbers to offer to CFOs. "If we invest $100,000 now, we can save five times this figure over the next 2 years in system administration (restoring infected systems to a usable state), and possibly ten times more if we are able to avoid a security incident." Such arguments are hard to sell, and vendor case studies and customer testimonials are often insufficient to influence the decision.

I'm not entirely sold on admission and exit controls. I think they are technically intriguing but they are ultimately an automated method of compensating for the vulnerabilities of both end points and those that use them. I also think they are ultimately dangerous because they make users more dependent on automated security and less committed to understanding security and appreciating their individual roles in maintaining an effective security profile.

I'm tired of hearing claims that "users aren't sophisticated enough to secure their systems". I see evidence in elementary, middle and high school classrooms daily that this will not be a legitimate claim ten years from now. I also see evidence today that makes me pause and ask, "would we really be worse off if we invested security budgets in incentive-based rather than preventative programs?"

In every organization, there are users who are "computer savvy". They are eager to understand the technology they use. They appreciate the need for information and system security, and to the extent permitted in the organization, they proactively engage in the security process by implementing antivirus, antispyware, firewall and other desktop measures on their systems. They protect and change passwords regularly, and are suspicious of unsolicited mail and the potential for phishing attacks.

The trick is to get *everyone* as engaged as the "security power users". So I propose an experiment that requires the participation of two similarly sized organizations with similar security needs. Organization Alpha must solicit an RFP for a technology-based admission and exit control solution. They must calculate the initial investment and ongoing cost of administration and support of the solution over a period of two years. The organization must implement the solution, and monitor the cost and efficacy of the solution over the two year period.

Organization Beta is to take the estimated cost of the solution. Part of this budget is used for security training. Each training session should address a security measure typically compensated for by admission and exit controls - antivirus, antispyware, antispam, firewall, VPN... - and explain "why you need to implement this security feature" and "here's how to do it". Another part of the budget is to be used as a monetary incentive for employees who attend security training, and who successfully implement and maintain the security measure on their systems. A final part of the budget is used to provide quarterly bonuses to employees based on success the organization has in avoiding security incidents.

At the end of two years, the organizations should compare results.

Which organization will have a better result? Is security that exploits "employee need and greed" is as or more effective than one that exploits F.U.D. and perpetuates user ignorance? Vote!.

Archived at http://www.securityskeptic.com/arc20061001.htm#BlogID562 by Dave Piscitello  

Mich Kabay's 17 October 2006 Security Strategies Newsletter discusses the difficulties of identifying forged digital images in the absence of watermarking. Mich begins by explaining that image forgeries are "a growing concern" in criminal cases. The problem is actually a twofold one: many people quickly realize how forged photographs and other images can be used for fraud, extortion and other crimes, but few people consider how a prosecutor's case resting on digital photographs can fall apart if the defense can claim the photograph is not authentic (implying that this evidence has tampered with).

Mich also mentions the doctoral thesis of Micah Kimo Johnson, who presents three new digital image forensic analytical tools: illuminant direction, specularity, and chromatic aberration. I found find Mich's abstracts of each method intriguing enough to visit and read the thesis itself. I recommend you read both the newsletter and the thesis.

Archived at http://www.securityskeptic.com/arc20061001.htm#BlogID560 by Dave Piscitello  

A Smallville, USA mother and her three young children were killed in an automobile accident yesterday when her automobile was struck by a teenager who misjudged a traffic light at the intersection of Maple Avenue and Pine Street. The teen and his three companions also died in the accident. The community's reactions to this tragic event were captured in the local newspaper editorials. Some feared future accidents while others expressed outrage that the tragedy could have been avoided had town counsel been more responsible when installing traffic lights. Town counsel laid the blame on the shoulders of the Traffic Engineering Division.

The town counsel hired consultants to determine if some measures could be taken to mitigate future such tragedies. The consultants recommended that the red (stop) signal should be extended for 20 seconds in all directions at the intersection of Maple Avenue and Pine Street. The delay would dramatically reduce the likelihood of another accident.

The solution worked extremely well. Months passed without an accident. The community, however, soon complained that the 20 second delay created intolerable and unavoidable delays and interfered with business. Town counsel instructed its traffic engineers to reduce the delay to 10 seconds at the intersection of Maple Avenue and Pine Street.

Months again passed without an accident. The community prospered and the population grew. The community again complained that the 15 second delay created intolerable and unavoidable delays and interfered with business. Town counsel instructed its traffic engineers to reduce the delay to 10 seconds at the intersection of Maple Avenue and Pine Street.

Lather, rinse, repeat...

Two years after the incident, the traffic signal at the intersection of Maple Avenue and Pine Street has no extended red signals.

Imagine that Smallville is not a town but an organization. Maple Avenue and Pine Street are not roads but segments of an IP network. The traffic signal at the intersection of Maple Avenue and Pine Street is an Internet firewall. The organization has just witnessed a security incident rather than an automobile accident.

Too often, organizations behave exactly like the citizens of Smallville. Immediately following a security incident, management and users express fear and outrage. Management holds security staff accountable for failing to secure the organization's assets and hires consultants, who recommend that the organization enforce a stringent security policy. Management directs the security staff to implement the recommended security measures, which include two-factor authentication, role based access controls, encryption of sensitive information in motion and at rest, and other measures considered to be industry best practices.

The solution worked extremely well. Months passed without an incident...

Archived at http://www.securityskeptic.com/arc20061001.htm#BlogID558 by Dave Piscitello  

Ofir Arkin's published a really nice paper that lays out the spectrum of network admission control (NAC) features, explains (conceptually) now NAC operates, and analyzes the architectural flaws that can be exploited to bypass NAC and permit a rogue endpoint to connect to a "NAC protected" network. The paper describes the strengths and weaknesses of current software NAC solutions (DHCP proxy Authenticated DHCP, Broadcast listener, and CISCO NAC) and hardware NAC solutions (inline and out of band) and how the weaknesses can lead to bypass. This is very interesting reading. Check it out.

Archived at http://www.securityskeptic.com/arc20060901.htm#BlogID555 by Dave Piscitello  

Now that you've read my article on the dangers of neglecting identity management, you should read my partner Lisa Phifer's article, Identity management appliances reduce password cost, at Security Spotlight.

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID551 by Dave Piscitello  

My article, Neglecting Identity Management, is part of a six-article series published at Network World. The other articles cover a wide range of topics:

• Not having a security architecture
• Not investing in training
• Ignoring the insider threat
• Not protecting Web appliances
• Buying products with the most bells and whistles

You may not agree that these are the "top six" but you'll find them all interesting reading.

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID550 by Dave Piscitello  

I'm a long time advocate of employing application proxies. I had the opportunity to write a series of columns to illustrate a number of ways an organization can use an HTTP proxy as an additional line of defense to protect users from unknowingly disclosing sensitive personal and company information. HTTP proxies can also be used to keep inappropriate or potentially harmful content from entering the organizations' network. While the articles I wrote describe features of the Watchguard FireboxX HTTP Proxy, these articles are useful to anyone who wants to learn about the benefits an organization can derive by applying HTTP proxies in general.

The complete series of articles is now available at these hyperlinks:

• Basic and Advanced HTTP Proxy Uses

• Fireware vs. the Cookie Monster, Part 1

• Fireware vs. the Cookie Monster, Part 2

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID549 by Dave Piscitello  

Traveling by air these days is inconvenient, and as a security professional I will resist the temptation to whine about restrictions imposed on carry-on items. However, I will take my recent real world experiences to harp on policy definition and implementation.

In twoseparate screening instances, I have had the same items treated differently each occasion. My originating airport allowed everything I packed that was not specifically a liquid. These included a gel deoderant and a stick deoderant (I packed both with the expectation I'd have at least one upon arrival). Less than 24 hours later, the TSA agent who pre-screened items before X-Ray confiscated my gel deoderant but permitted my stick deoderant. After passing through X-Ray, a second TSA agent insisted that my bag be hand-examined. The object that attracted her attention was of course the stick deoderant. She opened the deoderant, scowled at me and claimed it was a gel. I made the mistake of defending my actions, explaining that "The other agent hand examined the stick and told me it was OK". Not satisfied with my reply, she called the other agent over. They proceeded to argue whether it was stick or gel for several minutes. In fact, the label on the deoderant said "gel stick". I suggested that since it was a trial size and nearly used up, I was more than happy to leave it, but by this point, the agents were wrapped up in a testosterone contest.

A post-mortem analysis suggests that one or more of the following failure conditions were encountered:

• The security policy was either hastily or incompletely defined.
• The policy was not communicated to the agents in adequate detail.
• The agents were not responsible enough to read it thoroughly.

The lesson? Security policy implementation can only succeed when policy definition, dissemination, and consumption are correctly executed.

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID548 by Dave Piscitello  

I was asked this question several times during a back to school event. Realizing no one wants to be presented with an exhaustive list in a casual setting, I offered a simple, "any printed material that contains information you should or prefer to keep private". Given the worrisome increase in phishing and other forms of online identity theft, I'm actually encouraged that people are thinking about protecting their identities and other sensitive information in formats other than bits in motion and bits at rest.

I don't have statistics but I'll speculate that dumpster-diving for personal information is still a profitable venture for organized crime. With the increased emphasis on recycling paper, it's also become a less odious (and odorous!) task. Given that you can now buy a decent paper shredder for under $20 US, many people can afford to reduce the risk of identity theft by shredding. An extreme "shred everything" approach probably requires a industrial grade shredder, so here's a list of what I consider the highest risk papers. Before you toss these items in the recycling, consider shredding them:

• Credit card, loan, bank statements and any correspondence on which a complete account number is printed.

• Insurance, medical plan, and any other correspondence on which a complete social security number, claim number, or record of service is printed.

• Pay stubs, Social Security, retirement and other "benefits" statements.

• Credit card offers.

• "Debt consolidation" and Cash Advance checks financial companies send you (I call these "debt expansion" checks). Blank checks from expired accounts? Sure.

• Utility bills. There may be enough personal information on a utility bill for a prankster to impersonate you and arrange for your electric, gas, telephone, and water service to be terminated.

• Correspondence that contains your full mailing address and phone number. If you've taken the time to arrange for an unlisted phone number but have provided it to a creditor, there's no point in leaving it for someone bold enough to dredge through trash to find and misuse it.

• Any paper on which you or a creditor has written credit card and ATM PINs.

• Pages or covers of mail order catalogs that contain your address and customer number.

• Children's school work. Sadly, these all pose a real threat. Your child's artwork, tests, and even homework in have powerful social engineering potential. Class trip announcements and after school activity schedules post threats as well, since they identify where your child will be and when.

• Truly personal correspondence - love letters, cards, you no longer care or dare to keep.

• Photographs (see "truly personal" above).

My wife just entered my office, and asked why I was rifling through my recycling bin. I explained that I was emulating a dumpster diver. She shook her head, gave me with one of those, "that's pathetic..." looks, and left. I suppose that's a good indicator that I've milked this thread for all it's worth.

[Note: if you want to add to the list, send me email...]

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID547 by Dave Piscitello  

Colleague Anton Chuvakin wrote an interesting (in his words, "fun") piece on this subject at O'Reilly SysAdmin. He provides accurate lists of both pro and con arguments. I won't reproduce them here but encourage you to read his article. Anton concludes his piece with, "the explosive combination of the march of ever-more-critical new connectivity technologies with the presence of dedicated evildoers will, in my opinion, guarantee that information security will remain relevant, vital and fun for years to come! Security technology innovation will not dry out any time soon".

If we do ever achieve closure on security I for one will be interested to see if anyone notices. Such an "event" will not be as newsworthy as banning liquids and carry-on bags on airplanes, unauthorized disclosure of personal information of tens of thousands of U.S. veteran, or an worm that infects and freezes iPods.

The biggest problems in security are rooted in human behavior and not technology. Scams, theft, and abuse antedate computers and networking. I am confident that programmers will write code securely and that operating systems and applications will be hardened on initial boot *long* before consumers of technology pay sufficient attention to security to make an event like "computing and the Internet are finally secure" meaningful.

Ironically, an announcement that security is done is probably the most pernicious event an attacker could conceive. Society would react by lowering its already pitiful guard entirely. Talk about adding fertilizer to a green field.

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID546 by Dave Piscitello  

I received an email today from a retired network engineer requesting permission to incorporate materials from a presentation I gave called 10 Most Commonly Overlooked Security Hazards into a lesson plan for a university level seminar he was preparing on network security. In his email, this gentleman said, "I was impressed by the correctness of what you have said. In my capacity as the network engineer for [...] I have often vented many of those same thoughts. I was frustrated enough that I retired in May of this year. It was refreshing to hear someone else with higher pedigree than I say those things."

Retiring from practicing Internet security is becoming an alarmingly recurring theme. At TechnoSecurity 2006, I spoke at length with two well respected security experts who are thinking of pursuing alternative careers, and another long time colleague has also indicated that he is leaving the security community as well.

I can't discount all of these decisions to midlife crises, and in fact, empathize with these folks more than I care to admit. Dr. Stephen Kent and I wrote an article for BCR entitled "The Sad and Increasingly Deplorable State of Internet Security" several years ago. At the time, several readers commented that "increasingly" was a poorly chosen descriptor. But all evidence suggests that Steve and I were spot on with our description.

• Security policy development is generally a poorly administered activity. Where policies exist, periodically reassessing policy and routinely auditing networks to test compliance are not assured.
• Access controls still lack granularity. The majority of egress traffic policies on residential and SME firewalls undoubtedly remains "allow any to any host". ISPs refuse to validate source IP addresses.
• Perimeter firewalls and desktop antivirus software are still the only lines of defense for most organizations.
• Default software installations, network and system configurations are as exploitable as ever.
• Authentication remains largely passwords-based, and folks are disclosing passwords for candy bars!
• Auditing and routine testing are haphazard activities, often performed under duress (BTW, incident response, forensic analysis and attack post mortems don't count...).

The experts who are jumping ship largely concur that technology alone can't solve these problems. I agree. But leaving the asylum in the hands of the insane isn't the answer.

At this point, I'm increasingly (there's that word again) inclined to believe we need to create rewards-bases systems that give employees (financial) incentives to compute, connect and communicate securely. Perhaps we need to complement technical expertise with expertise in behavioral psychology.

Now wouldn't that be an interesting career jump for a disillusioned security expert?

Archived at http://www.securityskeptic.com/arc20060801.htm#BlogID542 by Dave Piscitello  

I attended and spoke at TechnoSecurity 2006 in nearby Myrtle Beach, SC. This conference is very forensics-oriented and attracts many accomplished and renowned security experts as well as law enforcement agents and other professional investigators. Some presentations and speakers I found particularly interesting were:

• Mary Ann Davidson, CSO, Oracle. Mary Ann spoke on improving IT Security using purchasing power, which is a deceptive and sleep-suggesting title for what was a very educational session. Mary Ann suggests that we have a better chance of pulling out of today's security tailspin if buyers become more demanding, if vendors pay closer attention to the hidden costs of patching exploited software and begin to develop more demanding secure coding practices, and if security analysts spend less time drawing magic objects and tell us more about real security issues. If you find a program where Mary Ann is speaking, I strongly recommend you attend that conference.

• Johnny Long and Cynthia Hetherington demonstrated how investigators and forensics staff can use Google and dozens of other web portals to public databases to identify and build leads for criminal and civil investigations, identifying along the way exactly how little privacy we all have. Cynthia's presentation, while very upbeat and humorous, was also very sobering. From information in a local newspaper article, Cynthia demonstrated how she and other investigators can in many cases use electronic "leads" to build a profile and collect evidence for defense attorneys and prosecutors without requiring a subpoena.

• The Expert panel on Tuesday afternoon included Johnny Long, Eric Cole, Marcus Ranum, Richard Bejlich, Ron Gula, et. al. The Q & A quickly digressed to a no-holds-barred, broad-reaching indictment of the myriad ways users, vendors, IT staff, and the press have contributed to the lamentable state of security. I laughed, I cried, it became a part of me.

I participated in an expert panel on Wednesday. I gave a short speech on "Impersonation" as the single most worrisome problem facing the Internet today. Later, during Q & A, I talked quite a bit about *accountability* and how society must play a role in reversing the downward trend in security. Forensics is out of my bailiwick so I worried that I would be perceived as some evangelical maniac but was quite pleased when a number of attendees spoke with me at the conclusion of the session and agreed that we really have to reverse popular thinking that includes such misconceptions as "hacking is glamorous" and "the security of my company's network isn't my responsibility", and begin to nurture ethical behavior and self-accountability. Wouldn't it be refreshing to read "ethical hacking is an oxymoron" and "hacking is a criminal activity" in tech editorials? Wouldn't you love to see a generation of employees who believe "working for my company is a privilege and I should show my appreciation by doing everything I can to protect my company's electronic assets" or think "it's my responsibility to make the best possible effort to assure that the code I write is secure before it's released"? And how about, "employees in my company are rewarded for helping us reduce our risk"?

I told you it sounded evangelical...

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID532 by Dave Piscitello  

Ask ten security administrators to identify their biggest security concern today. The majority will identify worms, spam and application-level (Web) attacks. A smaller number will respond that user and access management trouble them. Chances are the administrators in the minority are managing the largest, most diverse organizations. More...

This article was originally posted at Interop Loop. I've finally resurrected it from the ashes of that info portal.

Archived at http://www.securityskeptic.com/arc20060201.htm#BlogID504 by Dave Piscitello  

I've been complaining about the desperate state of user account and identity management for some time. To date, the single and reduced sign-on solutions I've had the opportunity to evaluate have proven wholly unsuited for medium businesses of between 500-2500 users. The IdM solutions SMBs can afford are lame, and the products that can actually solve the problem target the large enterprises that are suffering in Dante's identity inferno and willing to pay six figures or more for relief. This is a dreadful situation because many companies might be able to avoid some of the growing pains related to Quad-A (admission control, authentication, authorization, accounting) and control the proliferation of user accounts if they could only find a unified identity management solution that was affordable, deployable, and scalable.

In December, I joined the advisory board of A10 Networks. Before joining, I shared my not-so-favorable opinions of the current state of IdM with some of the company's principals. A10 piqued my curiosity by flatly stating that they had considered all my complaints - well, at least the ones that technology can attempt to solve - in the design objectives for their IDSentrie identity appliance. In fact, they insisted I test drive an IDSentrie 1000 and sent me an appliance shortly after our first board meeting and a box was literally waiting for me when I arrived home.

In its simplest deployment (which also proved to be a useful introduction to the product), IDSentrie proxies authentication requests from access server devices (firewalls, remote access/VPN servers, WLAN access points, web portals, etc.) to 3^rd party authentication data stores using common authentication protocols (e.g., RADIUS, EAP) and popular auth methods (passwords, digital certificates, SecurID hardware tokens). Using the IDSentrie web GUI, I began by configuring two firewalls as network access devices. So I could test one communications path at a time, I configured users and groups in a local database at the IDSentrie. When configuring groups, I identified the access server, auth method, and access control elements that comprise the AAA policy I intended to enforce. I then configured the firewalls to forward authentication requests to IDSentrie using the RADIUS protocol. My firewalls had previously been configured with a number of user-based access policies, so I attempted to visit a web site that hosted restricted content This forced me to authenticate to the firewall, which passed my credentials to the IDSentrie using RADIUS. I repeated the process to test the RADIUS exchange with my second firewall.

This wasn't much of a test; after all, I could do this with many RADIUS servers. I next attempted to enable IEEE 802.1X authentication and WPA/AES encryption through a Linksys WAP55AG access point. IDSentrie has a built-in SSL server certificate and supports several EAP types, including EAP-TTLS and PEAP and auth methods (MD5, MSCHAPv2, SIM). I chose PEAPv0/EAP-MSCHAPv2 authentication against a local IDSentrie database; again, while I could do this with other products, I wanted to keep it simple, early.

Configuring the Linksys AP as a network access server, creating a group and policies for 802.1x authentication and enabling the Linksys AP to forward authentication to the IDSentrie took about as long as configuring the Windows XP clients. I fired up a laptop, connected to my preferred wireless network, accepted the IDSentrie certificate (first encounter), and logged on using IDSentrie database credentials.

These are relatively simple scenarios, but I am juggling my IDSentrie play time with my day job(s). Still, I'm impressed at how intuitive and easy IDSentrie's made tasks that are quite a bit more complex. My next step is to introduce an Active Directory and a RADIUS authentication server into the mix. I've gone through the long and harrowing experience of configuring Secure IEEE 802.11 networks using Microsoft Windows, which requires a certificate infrastructure, Active Directory (for accounts, groups,and 802.11 group policy settings); and IAS services, so I hope to compare that experience with IDSentrie. Eventually, I will eliminate the IDSentrie local database from my environment so I can better emulate medium to large organizations where authentication data stores and servers seem to multiply like rabbits.

This is the first in what should prove to be a series of IdM-related posts. Since I disclosed my relationship with A10 Networks at the outset, I won't apologize for any evangelical comments, but I will try to keep them to a minimum:-)

Archived at http://www.securityskeptic.com/arc20060201.htm#BlogID499 by Dave Piscitello  

I followed a recent WatchGuard Wire report, Oracle fixes 37 security vulnerabilities to the actual Oracle Critical Patch Update. Mildly curious, I looked at the products and releases affected. Something about ORACLE 9i Database reminded me of a Larry Ellison quote regarding ORACLE Security. A Google search led me to a January 2002 interview in ORACLE Magazine. Excerpt follows:

ORACLE MAGAZINE: You've said that Oracle 9i is the last database. What does that mean, and what do you think is next for databases?

LARRY J. ELLISON: This isn't the first time I said Oracle was the last database. What I mean is that Oracle9i introduces a new standard for data management. Oracle9i is an unbreakable system. You can't break it, and you can't break in. It's very secure.

We've passed 14 different certifications to prove our database is secure.

So much for certifications...

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID496 by Dave Piscitello  

We live in an age where the Internet is the de facto media for publishing, collaboration, and information distribution -- whether in traditional on-screen data and print formats, or voice and video formats. This is likely to be a wonderful thing. "Everything over IP" is a decades old mantra. When everything is over IP, "everything" will include phone and fax calls, video conferencing, broadcast television and radio.

Enterprises have the ungainly task of reconciling traditional and emerging policies across different media. Content inspection technology for packetized data is bleeding edge when compared to how we might go about monitoring telephone calls, fax transmissions, and snail-mail. This creates a conundrum: You can impose more stringent rules for appropriate use of one media than for others, or you can strive for consistency in policy across all media. The real-time nature of Internet communications tempts organizations to impose stricter policies. In the long run, consistent policies will be easier to manage and enforce.

If you are dealing with these problems *today*, it may surprise you that my first Watchguard Live Security column discussed exactly these issues.

Then again, it may not surprise you at all.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID493 by Dave Piscitello  

John Dix wrote an article summarizing the security concerns and recommendations he considered most important from my opening and closing keynotes for the Fall 2005 Network World Security Tour. I've been remiss in not mentioning this article. If you didn't attend the tour and are curious enough to spend 5 minutes, read John's article, Lessons learned from The Network World security tour.

I have to give John a call to thank him. He got every quote right:-)

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID486 by Dave Piscitello  

Harry Potter is a thoroughly enjoyable read for children and adults alike. Harry is a thoroughly ethical young man and positive role model for many children worldwide. He'd make a good security practitioner.

If Harry *were* to set aside such attractive career paths as Auror or Professor of Defenses Against Dark Magic to become a security administrator at Hogwarts instead, his first act would undoubtedly be to eliminate the use of passwords as authentication credentials. For those of you who are unfamiliar with the Harry Potter series, Harry attends a school of magic called Hogwarts. Students who attend Hogwarts are placed into four "houses" by a magical Sorting Hat when they arrive for their first year. The Houses are named after the school founders: Ravenclaw, Hufflepuff, Gryffindor, and Slytherin. Harry is in Gryffindor.

The students of each house take residence in Towers. Each Tower has a magically protected entrance. In Gryffindor Tower, the entrance is hidden behind a large portrait of a fat lady in a pink silk dress. The students of Ravenclaw, Hufflepuff, Gryffindor, and Slytherin are told the "secret" password that gains them entrance to their respective Towers.

This is weak authentication in all its glory. The password is shared by every member of a House. It is a static password, changed annually. Moreover, the fat lady's password challenge never asks students for identity. I cannot recall any incident where a house ghost barred entrance to a student because he was a member of a different house and thus had no business entering. which could imply that facial recognition (biometric) is used. But if the house ghosts use a biometric, what's the purpose of the password?

Perhaps the password is a second factor to the biometric, to defend against impersonation. Remember, this is a school of magic, and JK Rowling describes many spells and potions, including Polyjuice Potion, which transforms a person into the physical form of another person for one hour. Now someone has to make the potion (difficult) and learn the password (trivial). But this still begs the question of why a group password is used instead of assigning one to each student.

Perhaps the ghosts can't remember that many passwords.

To understand why I am making such a fuss over passwords at Hogwarts, you need a bit more information. Hogwarts School of Magic is protected by all manner of powerful spells to repel evil spells, keep evil magicians from entering the school, and to hide the school from muggles (people who can't practice magic). This is an envious set of perimeter defenses. Within the perimeter, however, Hogwarts relies on group passwords to control access to individual houses, which is markedly less rigorous.

Does this sound like any networks you know?

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID478 by Dave Piscitello  

Today's question from the NWW Security Tour 2005 is

Our college has a limited budget for security. With threats at so many levels, would it be prudent to focus on one specific vector (i.e., email, apps, web, firewall/IDS/IPS)?

To answer this question in a qualified manner, I asked colleagues who run IT departments at universities and colleges where they focus their time and attention.

The first reply I received suggested honeypots. At first, I was surprised, but reconsidering, I realize that this is actually a very practical security activity at a college, where talent is plentiful, the cost to acquire it is low, and where legal recourse for perpetrators isn't limited to civil and criminal prosecution (the University, for example, can dismiss the student).

Admission control appears to be security activity of equally high priority to universities and colleges as it is to enterprises. Keep infected and poorly maintained client devices off your network and you'll reduce the vectors for malicious code.

Improving security of wireless LANs is also mentioned. Broader adoption of IEEE 802.1x is consistent with admission control initiatives.

My $.02. Leverage the availability of the talent that surrounds you. Convince the young, easily-influenced, enthusiastic minds that counter-hacking and forensics is much sexier than attacking, and that involvement in University security activities will look terrific on resumés. Involve them in all those "arms and legs" activities that undermanned IT staffs everywhere struggle with. You'll not only earn a brilliant ROI for your institution, but you'll be "paying it forward" by increasing the number of security white hats.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID471 by Dave Piscitello  

Gather folks together to discuss application and data security and you will invariably find at least one cynic. The Network World Security Tour 2005 in Seattle had several cynics (imagine...). One asked,

Can you convince me that holes are not left intentionally to "create" business for system security vendors"?

I can't provide convincing evidence that such behavior is non-existent in the industry. I can't provide any concrete evidence of instances where bugs have been intentionally planted, either. But given the sad state of software development, I can't really imagine that anyone would bother. There are *so* many lines of code written daily, with little or no review for security flaws, and the barest of efforts at quality assurance, *contriving* bugs strikes me as about as pointless as importing sand to Saudi Arabia.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID469 by Dave Piscitello  

This question from a NWW Security Tour 2005 Q & session was interesting because it illustrates how assumptions can lead us astray. The first assumption here is, "encryption will become ubiquitous." Let's assume that this is true. The fact that encryption is ubiquitous does not guarantee that it will be end-to-end, from client-to-application, in all cases, nor does it imply that it will be applied at the same protocol level. Organizations may use SSL from client-to-proxy over external (e.g., Internet) connections. The same organization may use site to site IPsec to connect its many locations, and WPA over wireless LAN segments in trusted internal networks. I envision these solutions as all comprising a typical deployment in the future.

Where an organization deploys IDS/IPS should be influenced by the kinds of attacks it wishes to detect and block. An organization concerned about denial of service attacks benefits from a firewall with DOS IPS capabilities protecting its internal networks at or near Internet access circuits. If the Internet-facing firewall terminates IPsec tunnels and the worry is DOS and other network attacks vectored through these tunnels, then place IDS/IPS between the Internet firewall and internal networks. Firewall/IPS appliances will (eventually) provide DOS protection, VPN termination, and IPS for network as well as application level attacks; using best of breed appliances and software (proxies) will always be an alternative to multi-purpose security systems.

Similarly, organizations using SSL for remote access can inspect user traffic for application level attacks at or behind the SSL VPN appliance, using application proxies (my choice) or deep inspection IPS solutions. Organizations that use SSL/HTTPS to protect traffic from client to application can use host-based IDS/IPS on individual servers, or terminate SSL at a switch/firewall that protects the server farm/data center, using a switch that is IPS-enabled.

IDS/IPS aren't obsoleted when encryption becomes ubiquitous. The considerations for where to implement IDS/IPS in a network merely change.

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID468 by Dave Piscitello  

In January 2003, I published an article, Blocking Public Instant Messaging. Today, I received a email from TechTarget's SearchSecurity.com inviting me to read Mike Chapple's similar security tip entitled How to block IM applications in the enterprise. I read Mike's tip to learn if admins had learned any new tricks in blocking IM. Along with the recommendations I published in 2003, Mike's added an interesting one: use the Software Restriction Policies in Windows Local Security policy (secpol.msc) to block the installation of IM applications.

This is indeed a good idea, and I'd add that enterprise IT admins can perform the task by create a Group Security Policy to restrict IM application installations using Active Directory and can push the policy to all managed desktops.

Even though Mike adds a caveat to this approach, saying, "You'll need to do this for every version of IM software released by all of the major providers – AIM, Yahoo!, MSN and ICQ", he overlooks the popularity and availability of multi-protocol IM clients, and thus underestimates the scope of the solution. I did a cursory search and found over a dozen IM clients, including GAIM, Trillian, Miranda, Psi, ICQ, Odigo, WWIM, &RQ, Beenut, myJabber, and Instan-T. And of course most P2P software (Skype, pulver.communicator, GoogleTalk, shinkuro...) support messaging. .

Basically, blocking IMs remains a formidable task. In 2003, I suggested admins combine firewall, routing, and name server measures with monitoring tools. Mike adds, "combine these techniques with strong desktop management policies and you'll have the best chance of keeping your network free of IM activity."

"Free of IM activity" is probably a bit optimistic. New clients and messaging protocols may simply appear too frequently and, like Skype, may become too elusive to isolate and block.

It's no wonder that a related link from the page with Mike's column discusses an increase in IM threats. Could there be a greener field for attackers than ever growing set of consumer grade, firewall-evading client applications that encourage promiscuous file sharing and in many cases, were developed without the benefit of the specifications of the multiple IM protocols they try to support?

Archived at http://www.securityskeptic.com/arc20051001.htm#BlogID464 by Dave Piscitello  

At the San Jose Network World Security Tour, an attendee asked an interesting pair of questions regarding archived data protection.

How can you ensure that archived data are tamper proof?

A popular means of protecting archived data against tampering is to employ encryption. If you only wish to verify that archived data have not been modified, you can compute a hash of the data using an MD-5 or SHA-1 algorithm when you create the archive. Save the hash separately from the archive. When you choose to restore or access the archive, compute the hash of the data you restore, and compare this hash to the one you computed and stored when you created the archive. If the values are identical, the archive has not been altered.

You can also digitally sign a hash when you compute it. This provides a means to verify the identity of the party who created the archive. And of course, you can use a bulk encryption algorithm to encrypt the entire archive to protect the data from unauthorized disclosure.

Many products are available to perform these functions, including Pretty Good Privacy Desktop.

The second question regarding archived data is interesting as well:

How can you ensure that archived data are deleted after a desired retention period expires?

This is achieved by marrying a scheduling process with a secure deletion/erasure technology. When archiving data, you must identify the retention period for the data. When that period expires, the scheduler should pass the archived data to a program that can securely erase the data. If you are using removable media, this process may involve some manual intervention, e.g., arms and legs activities to place the media in a device where software can delete the archived data from the media. Finally, you may wish to shred removable media (DVD, tape, even hard drives) to prevent digital dumpster diving and unauthorized data recovery.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID460 by Dave Piscitello  

I have time to answer another question from the Network World Security Tour before I leave for a campus visit with my son. Again, I'll try to answer as I would if we'd had the opportunity during the Tour Q & A.

With the convergence of network and security devices, how does an organization guarantee the security of the security device?

This would have been my choice for "best question". Let's begin by considering the core software of a security device. The software model that I think results in a very reliable and trustworthy security device is one that is custom-purposed for security and security only. The code is very tight. No unnecessary software and services are included, and the code is carefully reviewed by security professionals. Protocol handlers and proxies are written to strictly conform to standards and interpret these in the most conservative manner possible.

Now, when security appliances begin incorporating routing, load balancing, and other networking functions, the security of the appliance *can* be put at risk. Why? Because security and complexity are opposing forces. Increasing the number and complexity of functions a device must support makes accurate and secure software development more difficult, and is one of many causes of exploitable code. A second consideration is "conservation of talent". The number of extremely competent security programmers is really quite small. The same is true for programmers who understand the routing protocols commonly used today. Even when a technology company finds competencies in both areas, that company still needs an extremely competent user interface design team that can keep the UI intuitive and feature-rich. Designing a UI for a security appliance is in my opinion extremely hard. Policy assertion through a UI must result in an unambiguous implementation or the organization will be more vulnerable to configuration error.

So how does an organization guarantee the security of a security device? If you are truly fearful of feature-creep, then you might choose best of breed and use singly-purposed devices in your network. But even this deployment is subject to configuration error, due to the degree of policy coordination you must introduce.

The simple answer is "test the hell out of your deployment". But this sort of empirical approach will tax any organization's manpower beyond most risk analysis. I'm not certain that an empirical method will ever suffice. Technology changes at too rapid a pace, as does policy.

Perhaps organizations can use "track record" effectively. Look at how widely deployed a device is. Get a measure of how the security community regards a device. How frequently is the device mentioned by experts as a candidate to solve a security problem of the nature and scale as yours? How frequently are vulnerabilities reported against the device you're investigating? How broad is the knowledge base and available expertise to administer the device? These metrics may seem to bias against the adoption of emerging technology, but if yours is an extremely risk-averse organization, you are probably *not* a candidate for bleeding-edge implementation. Internet history also illustrates that reputation builds (or deteriorates) as rapidly as technology: if a security product is disruptive enough to attract attention, it will undergo considerable scrutiny by security experts who will probably put it through more man-years of tortuous testing in laboratories than you could justify in your organization.

This was a long answer, and probably *not* what you wanted to hear. The short answer is "it's hard to do, expensive, and time consuming", which explains why it's not done all that often.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID456 by Dave Piscitello  

During a risk assessment, you identify and ascribe a dollar value to the (electronic) assets of your organization. Assets may include materials for which you have copyrights and patents, intellectual property, research, databases containing accounting, personal or similarly sensitive or regulated material, strategic and marketing plans. Any-thing "networked" that would cause you financial harm, expose you to embarrassment or legal action, inhibit or damage your ability to operate your business, or place you in violation of a government regulation is an asset.

Some assets aren't as tangible as others. The availability of your network infrastructure, your servers, and your endpoint devices is an asset. If you are an e-merchant or conduct a meaningful part of your business or derive substantial revenue electronically, availability is an asset. Actually, loss of availability is a liability: every minute you are not processing transactions and selling goods represents lost income. Companies whose communications and distributed processing for a manufacturing production line or parcel delivery service could be delayed or blocked by an attacker are as much at risk for loss related to availability as e-merchants.

Once you identify assets and have assessed their value, identify the risks to attack or threats each asset is exposed to. Unintended or malicious disclosure of pharmaceutical research, formulae or testing is a serious threat to a drug company. Disclosure of a patient's medical information is a serious threat to a hospital, and a violation of U.S. Federal Law. Modification of data is another kind of threat. Consider how a change the 4^th or 5^th decimal place of an interest rate used in amortizations will affect interest ac-crued or paid out. Imagine how a change in the 8^th decimal place of the value of pi might affect calculations critical to an unmanned space probe at NASA .

When developing a security policy, it's helpful to create a table or matrix. Identify

• Assets, their value, and location
• The nature of threats to each asset (disclosure, modification, theft, loss…),
• The ways in which assets are vulnerable to attack, for example,
  • Unintended or inappropriate disclosure of passwords, identity cards, etc., leading to unauthorized system or facility access,
  • Unauthorized file access, leading to unauthorized disclosure or destruction of sensitive information,
  • File integrity compromise, leading to errors in calculations, production problems, hazardous conditions, etc.
  • Unauthorized Operating System access, leading to misuse, inappropriate use, or malicious operation,
  • Denial of service or forced system or (server) software failure, leading to ser-vice interruptions, loss of revenue and business communications,
  • Theft of equipment, possibly leading to many of the above attacks.
• How you intend to remove (mitigate) or minimize the threat (file permissions and encryption measures you will take to protect file accuracy and availability; prevent unauthorized access; ways you will detect and block a denial of service attack…).

If you don't know what's at risk, and what threatens your assets, how can you take measures to protect them? If you don't know how much is at stake should an asset be lost, destroyed, stolen, or disclosed to unauthorized parties, how can you determine if you're spending enough or too much to protect them? Similarly, if you don't know the approximate per minute or hourly value of offering e-merchant service, how can you determine if you are taking adequate measures to remain on line?

Risk, threat, and vulnerability assessment can be a very complex process, and it's important that you have credible valuation of assets should you seek financial restitution in courts of law following an attack. Hire certified outside security auditors to perform a risk, threat and vulnerability assessment. If you choose to perform these assessments yourself, review guidelines established by organizations like The Information Systems Audit and Control Association & Foundation (ISACA) before you pursue this yourself.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID451 by Dave Piscitello  

A side-effect of using Google AdSense is that I discover companies who offer products and services related to articles I post to my blog. Some of these have proven undesirable, and I've already written about the problems I have filtering rogue spyware product advertising from my Anti-Spyware Resources page. I've nearly exhausted my filter list allotment and have long passed my patience with this deception, so I will remove advertising from that page.

There are positive outcomes. After posting my article on security policy, I visited some of the AdSense advertisers who develop software to automate policy development and maintenance. While in no way endorsing these companies or products, I can point you to some additional examples of policies and policy templates.

If you are interested in a HIPAA Security Policy, visit HIPAAacademy.net and look at their templates

If you're interested in reading about compliance, try one of the ebooks offered by NetiQ. .

Lastly, you can download a full "watermarked" trial version of a set of Information Security Policies from Information Security Policy World.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID449 by Dave Piscitello  

Every organization needs a set of guidelines that identifies the assets the organization deems valuable or sensitive, and describes appropriate use and handling of such information, and what constitutes authorized access. A security policy identifies threats to an organization's assets and measures to take to mitigate or reduce these threats. A security policy also documents processes for maintaining security and for responding to attacks or incidents. It identifies conditions that necessitate escalation, disclosure, and notification of law enforcement, public relations, and legal responses. A security policy says, "here is what we value, threats that put what we value at risk, how we intend to protect what we value, and what we will do if it should ever be lost, damaged, disclosed without authorization, stolen, or attacked".

Few security activities are as routinely overlooked and discounted as security policy development. A common complaint every security consultant hears is, "Why bother developing a security policy? Assets, technology, and needs change constantly!" To this, I answer, "Change is a constant, not an excuse." Without guidelines on which to base security measures, organizations lack a comprehensive strategy for protecting assets, and so make ad hoc and technology-driven decisions. The result is security measures that don't satisfy all the criteria for adequately protecting assets. Too few members of an organization will know, appreciate, and consequently, comply with security and acceptable use policies (AUPs). [A good example of an AUP is the Acceptable Use Statement for NAS Systems Division Computing Resources. Other AUP resources are listed at the end of this article.]

Why are security policies important? Lacking policies, an organization cannot know exactly what it is they are trying to protect, what measures they expect implement to protect it, who is responsible for implementing these measures, and who is responsible for assuring that the measures are implemented as intended. The organization at large may not know how to react to an attack, and it will have little or no basis to hold insiders or attackers accountable for their actions. When such action or response plans are not provided, maintaining security standards, responding to security breaches, and taking remedial action are ripe with uncertainties and grow increasingly challenging as the organization grows.

Who should develop a security policy? Technical staff are important contributors, but when security policy is placed entirely in the hands of IT, the valuable contributions "non-technical" members of the organization can input to a security policy are overlooked and lost, often to the detriment - and expense - to the organization. Always engage representatives from legal, accounting, auditing, personnel, key business units. These parties can provide valuable input, especially in circumstances where a security policy must consider an organization's liability, accountability, regulatory obligations and business objectives. When you have completed your security policy, share it and have all parties sign or otherwise acknowledge their responsibility and accountability to the policy, and then consider implementation.

When should you develop a security policy? Few organizations today have the luxury of developing a policy before computers are used and networked by an organization. This really matters only with respect to how the security expressed in a policy is ultimately implemented. While I don't dismiss the challenge of incorporating security as a retrofit or upgrade to design rather than a fundamental consideration, it's still "an implementation". An important consideration regarding "when" is that a security policy should remain a living document within the organization. It should be revisited frequently, as assets, business objectives, and the regulatory environments that affect an organization change. Again, change is a constant, and security policy (and implementation) must respond and adapt to change.

Many resources, templates, and standards for developing a security policy are available on the Internet. The SANS Security Policy Project, the ISO 17799 Directory: Services & Software for ISO 17799 Audit, ISO17799 Compliance & Security Risk Analysis, the Network Security Library: Security Policy, and the Virginia Department of Education, Acceptable Use Policies: A Handbook may help you as you develop a policy for your organization. There are more online resources, to be sure.

None may precisely match your organization's needs, but these can serve as guidelines.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID448 by Dave Piscitello  

On your network, time synchronization is essential for correlating event data, auditing, and accounting. MyLiveSecurity article explains why accurate, universal time across your entire network benefits you, and how to accomplish this using NTP. More...

Originally published via WatchGuard LiveSecurity, 03 June 2005

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID444 by Dave Piscitello  

Internet security is often described in military terms. Many of these originate from the castle building vocabulary of England during the reign of Edward II. I've always found this analogy interesting. Recently, I received an email from someone who read an article I wrote in the TISC newsletter, entitled Server vs. Client-based Protection. In that article, I made a brief reference to Edwardian period castles. A year later, I wrote a section for a chapter of a book my partner Lisa and I never completed. I found that chapter and decided I'd revise and publish it section by section. Today, I'll compare the Edwardian period "security" to Internet Security.

Castles protected items of value and people of importance - the landowners and merchants - from miscreants, robbers, and armies of rival lords who would steal or destroy valuables, and injure the nobility, if not prevented from doing so. Castle designers employed layers of security to protect the donjon or keep, its occupants and treasure. Rudely constructed dirt fortifications improved over time to what we all imagine when we think of a "castle": a formidable fortress surrounded by moats, accessible only via a draw bridge, with yeomen and archers positioned on crenellated and battlemented walls of stone to keep intruders at bay.

Within these layers of defense, men at arms stationed at checkpoints allowed recognized inhabitants and authorized visitors to come and go as they pleased within the confines of the castle walls, but only permitted a privileged few to access the keep itself. Barred gates, tripwires and mantraps were used to block and delay intruders who managed to make their way past any given line of defense. Alarm fires and bells were used to raise a general call to arms when defenses were breached.

We deploy similar physical security measures today to protect computing facilities (Internet data and operations centers). We try to maintain a secure perimeter, a continuous fortification or enciente continue surrounding our networks and the electronic assets within. Physical security measures to protect networks and communications systems still include walls and armed guards at checkpoints. Electronic sensors, laser tripwires and even mantraps are common components of physical security where the value of electronic assets and the systems on which they are stored or operated is particularly high (e.g., financial institutions). Electronic swipe cards and biometric devices (fingerprint, iris, and palm scans, and facial recognition) replace and complement armed guards as preferred methods of verifying identities of those who have authorized access to secure facilities.

Physical security doesn't cover the problems associated with protecting electronic valuables and trusted communities of individuals (insiders) from miscreants, competitors, terrorists and rogue governments (outsiders), who could access these assets via an organization's Internet connection(s) unless measures were taken to prevent them from doing so. Additional security measures are often required:

Perimeter security enforcement systems - packet-filtering routers, firewalls, and application proxies - prevent unauthorized access and block attacks.

Authentication systems distinguish authorized users (members of the trusted community) from unauthorized ones.

Network admission and endpoint control prevent devices that are judged "unsafe" from connecting to networks.

Authorization services - on client and server operating systems and file systems provide additional access controls and govern the activities authorized users may perform.

Intrusion prevention, detection and blocking systems - Intrusion Detection Systems (IDS), tripwires, honeypots, anti-virus and server integrity software and hardware - provide additional lines of defense within the secured perimeter, and provide alarms warning administrators of security breaches.

A castle proved very effective so long as the treasures weren't moved and the population of the kingdom didn't venture beyond the stationary defenses their castles provided. But for nobles and their merchants, travel was inevitable and communication with other kingdoms necessary. Armed guards accompanied the noble's entourages and the merchant's trade wagons. Knights accompanied the wagons for added protection. Treasures were transported in strongboxes. Private correspondence was sealed and uniquely imprinted with wax and chop (or signet ring).

Networks and hence network security were also based on isolationist practices as well. But wholly isolated, private networks are as impractical today as isolated kingdoms were during Edward's reign. Most organizations must have Internet presence, and its employees must access Internet resources, from the office, at home, and while they travel. Thus, every organization today has information assets that must be protected from misuse, abuse, theft or damage from outsiders. Many organizations have mobile workforces and teleworkers. Increasingly, organizations allow business partners, customers and consumers to access information via intranets and extranets. Organizations exchange sensitive correspondence and perform business transactions electronically, over the Internet, as well. These organizations are growing more aware of the threats Internet-originated attacks pose, and want to protect access to their information assets, and to protect information exchange over the Internet of as well; so additional security measures are often required.

One of the most widely employed measures is Virtual Private Networkings (VPN). A VPN uses encryption methods to protect information exchanged over the Internet - or generally, any communications path that is not considered "trusted" (especially wireless networks) - from being read, modified, and replayed. VPNs also authenticate both ends (parties) of a communication. But VPNs are one of several measures required to maintain distributed security policy enforcement. Once a client and mobile computing platform ventures be-yond the security measures commonly provided by an organization at one of its facilities, it must be protected with commensurate security measures. Desktop anti-virus, personal fire-wall, system integrity, and IDS software extend an organization's security enforcement be-yond the physical and logical perimeter it creates at one of its facilities. Distributed security policy enforcement, layered security, and defense in depth will appear as recurring themes in WLAN security.

The analogy between Edwardian period and network security is interesting, accurate, and powerful.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID441 by Dave Piscitello  

A recent thread on the pen-test mail list raised the question of whether service providers should detect and block port scans emanating from subscriber hosts and networks. The question actually has many dimensions, and I'd like to discuss these:

• Who benefits from this service, and who is harmed?

• What characterizes the service, can it be truly effective or is it too easily evaded?

• Should the service be opt-in or opt-out?

The service benefits benefits the provider and backbone at large by filtering at Internet ingress points. If my firewall logs are reflective of the volume of scan traffic congesting the 'net, blocking port scans has to be A Useful Thing. Under normal operating conditions, the service also benefits every subscriber by lowering the noise to signal ratio of traffic delivered to individual hosts, Internet firewalls and packet-filtering routers.

The service interferes with organizations who want to observe incoming traffic and who routinely audit their security policy and use penetration-testing techniques. Penetration-testers of course, are hampered by the service, as it interferes with their ability probe network clients engage them to test for vulnerabilities.

A few examples of port scan blocking services were discussed on the pen-test list, and they appear to employ the same techniques many commercial firewalls now offer under the overused term "intrusion prevention". ICMP echo, UDP and TCP SYN/RST/FIN traffic exceeding certain thresholds is characterized as a scan and blocked by the ISP. It's unlikely that these services can detect all forms of stealthy scaning so one can argue tha