The Security Skeptic

The Register reported in March that Gabriel Bogdan Ionescu, incarcerated at a Penitentiary in Como, Italy, was admitted to the Polytechnic University of Milano and that a security? company was offering him a part-time job. In another article, Romania's general consul in Italy is quoted as saying, "the media here are presenting the exceptional intellectual qualities of this boy".

Will people never learn? It's not the intellectual qualities but the moral fiber that forms the core of a security professional and practitioner. I have the privilege of working with people whose skills would humble this e-fraudster (remember, if he was that good, he would probably be spending time in some of the nicer corners of Como). What distinguishes them from Ionescu beyond the intellectual qualities is the marked commitment to ethics. For any security endeavor, you want a hard core white hat, someone who won't compromise his integrity, your country's sensitive information, or your company's product for notoriety or money. If you start out with employees whose ethics are at best provably questionable, you're essentially building a home on a floodplain. You can deny all you want, and your home may avoid the inundation, but you're gambling when you don't have to.

Archived at http://www.securityskeptic.com/arc20090501.htm#BlogID728 by Dave Piscitello  

The typical security presentation invariably has a once clever, now tired, firewall icon. Marcus Ranum knows a fair bit about firewalls, and contends that not only does the conventional icon fail to convey "firewall" to the uninformed, it "looks like something a cat would sleep on".

Marcus claims that if you really want to convey "fire" wall, you need some fire. Visit Marcus' page, The Ultimate Firewall, and consider one of the compelling visuals you'll find in this article for your next security presentation. Alternatively, you can clear some open space, gather some flammable material and #2 Diesel fuel, and roll your own...

Archived at http://www.securityskeptic.com/arc20090301.htm#BlogID724 by Dave Piscitello  

Eugene Schultz wrote a nice piece in the August 2008 issue of the ISSA Journal on Identity Management. What I like about this particular article is that it is it's neither hype nor hard sell. Instead, Schultz gets to the heart of the hard realities of deploying identity management. Let me quote some of the good insights from this article and explain why they are spot on.

Schultz claims that it's critically important to achieve "a genuine understanding of the fundamental difference between identity management and identity management technology". I agree. Many IDM projects start and fail with the proposition that the organization simply needs new identity management technology to improve its security. A war story shared by one of my colleagues serves as a good lesson for any organization that's about to launch an IDM initiative. My colleague's organization had several minor incidents, all related to password sharing. How was this problem presented to management? "We have too many passwords to remember so staff often ask colleagues to share accounts when they forget their own." The organization introduced a slick RADIUS/AAA appliance to implement single sign-on but retained a user accounts policy that allowed short, static passwords. In this scenario, the organization had done as much to make an attacker's life simpler as it has to eliminate the problems created by password sharing. Password related incidents continued and with graver results. The lesson? Identity management requires careful planning at several levels - policy, education, technology, and implementation - to assure that the organization makes considerable gains in the security's Triple-As while continuing to meet the information networking needs of the organization.

Schultz also claims that an Identity management effort is "good only to the degree that the resulting mechanisms and processes are pervasive..." and that it must affect "every access to every system, network, application and database - with no exceptions." I strongly agree. An organization can't enforce an identity policy that applies to staff but makes exceptions to executives, or a policy that fails to address the challenges that guests, contractors, and mobility introduce. Similarly, an organization can't enforce an identity policy that is readily circumvented by staff who choose to ignore policy for expediency's sake, install a departmental database, and use the built-in user account system.

I'd also encourage Schultz and readers to consider expanding his notion of pervasive to apply to every access, by every user, from any endpoint. The most prevalent and pernicious activities besieging the Internet today are impersonation attacks. Thus, I strongly encourage anyone who is considering Identity Management to consider identities beyond the traditional Triple-A (Authentication, Authorization, Auditing) but also in the contexts of authenticity (data integrity and data origin verification) and admission control (verifying that an endpoint device poses no threat to an organization's information and networking asset before granting a user access via that endpoint device). For more on this Quint-A approach, read Improve your branch office security, one "A" at a time.

I've only scratched the surface of the many good insights Schultz offers in his article. He emphasizes the importance of developing requirements, setting criteria to assure that the identity solution scales well and is not overly complex, and determining that the solution is compatible with the existing IT environment (remember, it must be pervasive!). A very good read, indeed.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID701 by Dave Piscitello  

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  

Originally archived at http://www.securityskeptic.com/arc20070501.htm#BlogID620 by Dave Piscitello   now found here.

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 that they slow rather than eliminate scanning entirely. Slowing the scan doesn't prevent an attacker from gathering information and acquiring targets, and it's relatively easy to to automate scans. Since the majority of scans are automated, what are these ISPs really accomplishing other than reclaiming bandwidth? Well, they *are* interfering with pen-testing.

Once again, we encounter an "opt-out or opt-in" issue. The service has merit for a large population of Internet users. I don't mind having less noise on the 'net. I'm certain millions of PC users worldwide won't mind as well. I do object to being denied the ability to test my network perimeter defenses, and I sympathize with pen-testers whose practices and methodologies are disrupted. If ISPs want to invest in this kind of service, why can't they simply explain the service to subscribers, and allow them to choose? Well, one reason is probably, "it's htechnically harder to do this than just impose what we think is best for the majority of our customers".

Accepting this argument, let's suppose then that the default is opt-in (not my favorite choice). ISPs should still offer some means of temporarily disabling the feature to facilitate pen-testing.

The answer of course is the same as above. It's technically harder to do this than impose what is best for the majority of our customers.

If port scan blocking becomes widely accepted practice among ISPs, I see a business opportunity for "hosted 3rd party scanning". I wonder if hosted3rdpartyscanning.com is available...

Archived at http://www.securityskeptic.com/arc20050701.htm#BlogID429 by Dave Piscitello  

I gave two presentations at Interop on behalf of TechTarget.com. Both are list of ten security related matters. TechTarget has converted the presentations into pdf files and made them available online.

The first is Commonly overlooked security hazards, a list of ten practical guidelines you can put into place today to protect your network and critical data in the future.

The second is Foolproof initiatives to boost your network security, a list of ten most commonly overlooked security hazards and easy ways to prevent them from placing your network at risk (for some value of easy).

My "top tens" may not match yours. If you disagree, drop me an email.

Archived at http://www.securityskeptic.com/arc20050601.htm#BlogID412 by Dave Piscitello  

During a recent thread on the Firewall Wizards email list, one participant called attention to a familiar analogy used to explain Security. Four critical attributes of security are likened to the four legs of a stool. The four attributes, also known as the Four A's, were defined as

"Authentication (who are you)

Authorization (what are you allowed to do)

Availability (is the data accessible)

Authenticity (is the data intact)"

The analogy drawn is also familiar:

"Attack any of the legs and you seriously weaken or break the stool."

I believe this model is no longer sufficient because it does not include asserting the trustworthiness of the endpoint device from which a (remote) user will authenticate and subsequently access data.

Network admission and endpoint control are needed to determine that the device is free of malware (esp. key loggers) before you even accept a keystroke from a user. Read about these here and here.

So let's prepend "admission (endpoint device is free of malware, threats)" to this list, and come up with a 5-legged stool, or call it the Pentagon of Trust.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID410 by Dave Piscitello  

I wrote an opinion piece for Interop Preview 2005 with the proviso that I would be able to publish it here following the conference. In this piece, I present some of the arguments in favor of implementing "scan before connect" security measures.

Archived at http://www.securityskeptic.com/arc20050501.htm#BlogID401 by Dave Piscitello  

This is the week of learning how to recover lost passwords. The staff administrator at my daughter's school asked if I could show her how to password-protect files on her PC. I explained how to create a compressed (zip) file and password protect this in Windows XP. She asked if I could help her create a really strong password. I explained that there were many ways to do this but that it was equally important that she create a password that she would remember. She nodded in agreement, and I suggested ways she could also write it down so that she could recover it if she ever had a momentary (or longer) memory failure.

Showing novice PC users a new security measure is like lending someone Breck shampoo - tell two friends, who tell two friends, and shortly, I'll be hearing from a panicked individual who's protected a zip file and can't recall the password. Preparing for the worst, I decided I'd poke around for a program that cracks password-protected ZIP files.

I found lots of buy-ware and share-ware, and a few frankly dreadful freeware. I am tinkering with one promising utility, PDG ZIP Finder by Astonsoft, Inc. I need to play more with this freeware "beta" from 2001, and didn't find a privacy policy at the company site, so I won't include a link until I am convinced it's "really free" ware. I didn't see any obvious backchannels in my firewall log, but haven't sniffed the wire yet. They do include a self-promotion to try/buy Astonsoft commercial ware but I can forgive this if it's all they do.

I'll keep you posted.

Archived at http://www.securityskeptic.com/arc20050301.htm#BlogID376 by Dave Piscitello  

A new project at SourceForge provides a reconaissance tool for identifying attempts to use/abuse search engines like Google to gain unauthorized access to a web site, or to glean information that has not been properly access controlled and is hence "searchable". Check out the Google Hack Honeypot.

Archived at http://www.securityskeptic.com/arc20050201.htm#BlogID362 by Dave Piscitello  

During a recent rebroadcast of a West Wing episode, Full Disclosure, C.J. Craig, White House Press Secretary, is caught unprepared by a cable TV reporter who argues that President Bartlett and Leo McGarry are implicated in an attempted cover-up of Vice President Hoyne's affair. The New York Times reporter who interviewed Hoynes drops a floppie disk containing a pre-publication copy of his article of the Vice President in C.J.'s office. As a kid, I used to call this "accidentally on purpose"...

I found myself wondering, "Can visitors really bring removable media into the White House?"

Keyloggers and viruses and zombies, oh my!

Archived at http://www.securityskeptic.com/arc20041201.htm#BlogID343 by Dave Piscitello  

Firstbase Technologies has published a useful white paper on Portable Computing Device Security, one worth finding time to read.

I noticed while reading the paper that the authors don't mention undetected or malicious data

alteration or injection in their risk analysis. I think the potential for someone to change sensitive data and inject it into an enterprise from a mobile device or removable medium is significant, and deserves more attention than it commonly receives.

Imagine a scenario where an employee reports the following chronology of events: "My PDA was lost or stolen and remarkably, a rather decent fellow returned it to me." Where your average PDA user can express relief, security staffers have to view even noble acts such as these with some skepticism. An unsuspecting, non-technical employee might fail to detect that not only did the seemingly decent fellow "borrow" the device or removable media, but he altered the information, expecting that the corrupted data will be subsequently synchronized and uploaded into an organization. (Note that this is the same attack vector as a PDA-induced virus or trojan or keylogger).

Where's the harm? Imagine how subtle small changes to spreadsheet values or (worse) changes to an embedded calculation or formula might affect an audit, sales projection, or project assessment. Or perhaps the attacker modifies hyperlinks in word documents to lure employees to a phishing web site that has the look and feel of an employee Intranet, or B2C portal.

Bottom line? All manner of nasty activities are possible when someone has time, talent, and *your* data. The resulting incidents can be extremely hard to detect and resolve. As you develop your Mobile User Security Policy and implement security measures, don't overlook the data alteration risk.

Archived at http://www.securityskeptic.com/arc20041101.htm#BlogID333 by Dave Piscitello  

My column, Watch Out for Security Freeware Gotchas, is available at Security Pipeline.

Archived at http://www.securityskeptic.com/arc20041001.htm#BlogID321 by Dave Piscitello  

For the past two years, I've hosted the SC chapter web site of the ISSA. I maintained a security library of hundreds of security articles worth reading. Unfortunately, we could not muster sufficient numbers to meet ISSA chapter criteria. Last month, I retired http://www.issa-sc.org.

I have relocated the security library to http://www.securityskeptic.com/library.htm. I am also in the process of adding more articles and resources. The library has approximately 500 resources listed, and my goal is to double this by 2005.

If you have read a security article worth recommending to your peers, please email the hyperlink to me and I'll add it.

Archived at http://www.securityskeptic.com/arc20040901.htm#BlogID308 by Dave Piscitello  

In a September 2002 article, The People Side of Prevention, Joanne Cummings asked me about measuring prevention success, a metric that is both elusive and illusory in nature. At the time, I said, "The only way to measure prevention success is by a dearth of incidents" and added that the non-presence of incidents becomes "something that, over time, can make security investments seem like overkill". I offered the scenario of a security information officer who works at a large corporation that spends $25 million per year on security. He has used that budget well, implementing security technologies that have buttoned up the enterprise against any attacker. But without incidents to report look, here's why we need security he can't justify his budget to the satisfaction of business executives.

As we focus more on risk assessment and mitigation, we may find it easier to quantify prevention success. But you'll still find organizations want the virtual corollary of rows of attackers impaled on pikes along the entranceway of corporate offices. "How many attacks did we prevent today?" and "Did we catch any attackers today?" aren't now nor will they ever be very helpful metrics.

The people side of prevention begins with trust. Is it too much to expect that C*Os trust the security professional(s) they hire to spend wisely and do the best job possible? I did hire the most competent and trustworthy professionals, right? If I were a C*O, I'd love to have my CSO report, "absolutely no one even bothered to rattle our dooknobs this month because attackers have conceded we do security so well here". I wouldn't expect this result, nor would I use it to justify a reduction in spending. I would treat such a result as an affirmation that I hired the right people, and that my security investments were and remain justified.

Archived at http://www.securityskeptic.com/arc20040701.htm#BlogID283 by Dave Piscitello  

I receive requests to review or trial security software all the time. In the past, I've done so informally, and have included sentences or paragraphs recommending auditing, scanning, and other security tools and products I've found interesting and useful.

I've revised my review process and guidelines. I now spend more time evaluating "enterprise" class software than shareware, and will write formal reviews of security products. These will be posted at www.securityskeptic.com. An example is this month's review of Syhunt's Sandcat Vulnerability Assessment Tools.

I intend to perform these reviews as a community service. Vendors are free to solicit a review, with the following caveats:

• These are independent reviews. The views expressed in this article will be expressly mine. I will give vendors the opportunity to read what I publish for technical accuracy.

• I will not review any product where I have an advisory relationship or financial interest in the company.

• I will only review fully licensed, non-expiring versions of products. Since I may review a product over the course of several months before writing the review, I won't be bothered dealing with license renewals, trial versions with limited features, etc. Vendors with products requiring operating system environments other than those I can create here may have to ship equipment needed to perform the review.

• I will not accept any form of compensation for reviewing a product other than the continued, licensed use of the product.

• I will not publish reviews of products that I find entirely unacceptable. I'm not interested in killing companies. I will identify the show-stopping problems to the vendor with the expectation that my comments will help the company correct course and ultimately deliver something of use to the community.

• Vendors are welcomed to publish the review at their own web site, without alteration, with full attribution and a hyperlink back to my site and Core Competence. See Syhunt.com for an example.

I have limited time to do this sort of community service, so expect at most one review per calendar month. If you have any questions, please contact me.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID277 by Dave Piscitello  

Endpoint security. Admission control. Scan on connect. Is endpoint security some hitherto unknown problem for which there are no known countermeasures? Do the only practical solutions involve new hardware? Read the full article here.

Archived at http://www.securityskeptic.com/arc20040601.htm#BlogID270 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...

Archived at http://www.securityskeptic.com/arc20040501.htm#BlogID254 by Dave Piscitello  

A recent posting to firewall wizards illustrates two fundamental problems we absolutely must overcome before we can hope to improve security.

The post is a simple inquiry:

Im working on ... trying to connect to someone on ... using iChat AV to AIM...they get an error that says is probably caused by a firewall. If this firewall is put in by their network, is there anyway around it?

Problem #1. If we only think of security as an inconvenience and seek to circumvent it, no amount of technology and process can help us. The corollary to this axiom: If, in addition to playing network cat-and-mouse with attackers, we are forced to do so with legitimate users, we are truly hosed.

Archived at http://www.securityskeptic.com/arc20040301.htm#BlogID216 by Dave Piscitello  

A fellow bug-traqr posted a hyperlink of a Vancouver Sun article describing how students at Simon Fraser University had invented a device to deter laptop theft. The device combines a laptop lock with a radio transmitter. Users can leave their laptop unattended and be notified via a companion palm-held device if the laptop is moved.

This is in concept similar to proximity identification cards gaining popularity among HIPAA-regulated organizations. It's clever, but I'm not that convinced it is all that helpful. Straying even 10-15 feet from your laptop is a lot like leaving your purse to reserve a table at Starbucks.

A more interesting product would be something like a LoJack, a radio device in the laptop that law enforcement can use to track the laptop down. The problem is that a laptop isn't expensive enough (maybe the data are). While it might sound like something straight out of the original Mission Impossible television series, I could envision a value-added feature to the "LapJack": the radio device is a 2-way communicator, and the user can signal the laptop to boot, or secure erase the hard drive. After all, in many cases, the data on the laptop are more valuable than the laptop itself!

Archived at http://www.securityskeptic.com/arc20040301.htm#BlogID210 by Dave Piscitello  

Application protection. Application "intelligent" firewalls. Web application firewalls. Deep packet inspection. Content inspection proxies.

Synonyms? You bet. The most common term among these (and more) is application protection, a catchall term, applied generically to all security measures that protect application services. As you can imagine, you can protect applications in many ways in a network. So where is it best applied? Read my article.

Archived at http://www.securityskeptic.com/arc20040101.htm#BlogID197 by Dave Piscitello  

I speaking publicly and teach occasional seminars at universities. A question I'm frequently asked is, "which is more important: a certification or practical experience?" I suppose I'm asked this because I don't have a CISSP, ISSEP, SSCP, GIAC, or any of the major certifications, and folks are curious why I haven't sought one. Perhaps they wonder how I do what I do without one, or merely trying to goad me into a rant.

Are security certifications useful, or are they padding for resumes? If I were to hire someone, would their experience mean more to me than certification?

I think a certification managed and conducted by a trusted third party establishes an interesting baseline for competency in any discipline. And increasingly, certification programs require a minimum number of years of practice from professionals before they may take the exam, and some require re-certification and a commitment to maintaining competency. But ultimately, a certification is more like an SAT or MCAT. These, in my opinion, measure what you remember, what you have been taught, perhaps what you have learned from experience, and your ability to analyze a relatively small and contained information set in a small amount of time.

What certification programs do not quantify is whether an individual's strong suite is defining, designing, implementing or administering a secure system or network; whether he or she operates best as a leader or follower; works well in groups or alone ; reliably meets benchmarks; presents effectively to managers and subordinates; or performs well under stress. These are equally critical hiring criteria (to me), and are hard to evaluate without serious consideration of an individual's prior work experience. When hiring a security professional, I recommend you ask for and interview references. You may also want to seek out former co-workers or managers other than those referenced as well.

Certification and prior work experience are complementary, but experience ought to be prerequisite, and a certification a complementing corroboration of an individual's capabilities. But is this enough?

For a security professional, I think not. I believe that *character* is prerequisite to both experience and certification. An individual whose trustworthiness, work ethic, and professional integrity are unquestioned is the most important hiring criteria.

Archived at http://www.securityskeptic.com/arc20040101.htm#BlogID188 by Dave Piscitello  

My web server terminated unexpectedly at 1:51:15 a.m. on Friday December 19th. I was away from my office and unable to investigate and restore service until Saturday evening at 9:29:26 p.m. One of the lessons I learned from this experience was, "for small businesses, the "un" in uninterruptible is as much a function of battery life as capacity.

The incident did inspire me to write a bit about service availability and equipment reliability here.

Archived at http://www.securityskeptic.com/arc20031201.htm#BlogID186 by Dave Piscitello  

We've all heard the sound bite length explanations of stock market movement over the course of a day. National Public Radio's All Things Considered on Friday September 12th ran a semi-humorous report about how analysts attempt to distill millions of trading decisions down into the single factor reporters can explain in a single sound bite, e.g., the familiar down on profit-taking, up on optimism, reaction to news of a new Bin Laden tape, and the ubiquitous "trading patterns" of technicals.

The most interesting comment to me was from Lou Dobbs, who said there's not enough time on broadcast radio and TV to thoroughly analyze the situation, and that most people aren't really interested in a complex explanation so analysts and reporters alike resort to single factor analysis. Dobbs admits, "it's wrong, but it's expedient".

Since I categorized this under Security, I won't keep you waiting for the tie-in.

How many practices persist with regard to Internet Security despite the fact that we know they are wrong, and how often do we acknowledge that they we do them because they expedient?

• We use passwords for authentication.

• We program without regard to secure code review.

• We configure firewalls with ANY permissions on egress traffic.

• We allow Anti-Virus subscriptions to expire.

• We ship equipment and software with default settings that accommodate ease of use rather than assure secure operation.

• We put equipment and software into production environments with the dopey default settings the vendor configured.

• We patch as patch can.

• We budget for security in a vaccuum.

• We audit annually, or when it is demanded.

Feel free to email me with your pet "wrong but expedient" security practice.

Archived at http://www.securityskeptic.com/arc20030901.htm#BlogID123 by Dave Piscitello  

Originally written for Networld+Interop 2003 Las Vegas Preview

All security systems - Intrusion Detection, Firewalls, packet filtering routers, authentication, VPN, web, mail and DNS servers, and the operating systems such server applications commonly run on - record security related activity, or events. This activity, commonly called logging or auditing systems, helps security administrators determine if security policy is implemented correctly, and if systems have been or are under attack. Logging and auditing information is invaluable in reconstructing attacks, to learn how the attack was performed, what security measures failed, and as importantly, to learn what damages were inflicted by the attacker. If handled according to conventional evidentiary procedures, security information gathered from logs and audit files can be used in courts of law.

Given the significance of security information, it's hard to believe that security administrators still struggle to gather and integrate event-related data from all their security systems into a single database where they can correlate the information, and then analyze it. Let's examine why this remains such a problem.

Most systems that log security event data generate volumes of information, since they may log how every packet, URL, user login, file transfer request, etc., was processed. Firewalls and IDSs that protect large Internet data centers and enterprise networks commonly accumulate megabytes of logged events daily. It's easy to imagine how quickly the sheer volume of information becomes impossible for one person or group to collect and correlate, much less analyze. The management of all this security information is further complicated by the fact that there is no convention or standards for how log records are composed, so security administrators must familiarize themselves with many different formats and normalize these diverse messages so they can correlate and interpret "like" events. Finally, only very experienced security administrators can realistically analyze security data and distinguish a subtle computer attack from "networking as usual".

Solving these problems - security information collection, normalization of diverse information into a common format, and intelligent, automated analysis of security information - is the Holy Grail the industry calls Security Information Management, SIM.

A large number of security companies are actively pursuing SIM solutions, including Cisco Systems, Computer Associates, Enterasys Networks, e-Security, GuardedNet, IBM, Intellitactics, netForensics, NetworkIntelligence, NetIQ, MicroMuse and OpenService. They share a common objective: provide a platform that security administrators can rely upon to process security information, identify trouble, recommend remedies and ultimately, even react to correct a mis-configuration or mitigate a discovered vulnerability before an attacker can exploit it.

Archived at http://www.securityskeptic.com/arc20030501.htm#BlogID34 by Dave Piscitello  

An interesting trend in worms is subject lines professing to contain patches to protect or disinfect a virus.

Of course, these mail messages these contain a virus. So in addition to the ovious social engineering subject lines like "RE:Hello", and "Hi", beware of opening email with subject lines such as:

• An IE 6.0 Patch

• W32.Elkern removal tools

• Worm Klez.E immunity