Dan Griffin's Blog

Comments on security, PKI, smart cards, cryptography, and entrepreneurship.

Summary: Poland is beautiful, the people are great, and hacker
conferences rarely disappoint!

Here’s where I’m staying (an apartment located next to this square) -
http://www.cracow-life.com/poland/krakow-market-square. The apartment
itself is very European! My only complaint is that, being right on the
main square, people don’t start quieting down until after 2am. Then
again, I’m jetlagged, so it doesn’t matter.

The keynote this morning was Joanna Rutkowska. While I didn’t see her
presentation at RSA (slides for that are here -
http://invisiblethings.org/papers/Security%20Challanges%20in%20Virtualiz
ed%20Enviroments%20-%20RSA2008.pdf), I do think her session this morning
was based on the same deck. The prototype her lab has done on nested
hypervisors (http://bluepillproject.org/) looks cool, as does the work
they’re doing on Phoenix HyperSpace
(http://www.phoenix.com/en/Products/Browse+by+Products/Phoenix+HyperSpac
e/default.htm).

I had the unfortunate distinction of being the first speaker after her
;) Most noteworthy of my presentation was an informal poll I conducted
at the beginning - namely, whether anybody travelled farther than me
(Seattle is 12 hours of flight time from Krakow) in order to be here
this week. The answer, out of approximately 350 people, appears to be
‘No’. I don’t think I should be proud of that, though …

Seriously, I received good questions during my talk, such as why Vista
to Vista IPsec uses 3DES by default, rather than AES, for example.
Anyone know? I note that AES isn’t even available in the IPsec policy
snap-in. My guess would be that this is dictated by the standard, or at
least was at the time of implementation.

Also, why all installers automatically run as Administrator on Vista.
This actually came up initially during Joanna’s talk, and was re-visited
during mine. She correctly observed that the recommended behavior for
Windows application installers is to place their binaries under
“\Program Files”. Hence privileged access is required. The question is
whether major application compatibility problems would be incurred by
limiting installer privilege by default. For example, instead of full
admin, use an account with only append rights.

That suggestion is misleading, though. There will continue to be a need
to allow at least some installers to run as admin. Thus, the bad guys
will have an out. Whoever is configuring the system is going to have to
make a “reputation” decision before installing software. As in, do I
trust the company or person that provided me with this installation
package? Professional system administrators are expected to make an
informed decision and then lock down the environment (and, in theory,
not grant users administrative access).

The majority of home users, on the other hand, remain susceptible,
having to make the same judgments without the benefit of IT experience.

Permalink | Comments (0)

JW Secure customer and Microsoft Network Access Protection (NAP) partner Blue Ridge Networks has been referenced as an early adopter of the new Forefront + NAP kit from Microsoft’s Solution Accelerators team.

Permalink | Comments (0)

I’ve found a variety of links on securing SharePoint servers. However, many of them date back to the first release, and others are just incomplete lists. My intent here is to aggregate an up-to-date list, and I’m seeking community feedback on keeping it current. This post is more of a prose format than a checklist format, but my intent is to refine the content first.

Most of the tricks to keeping a server in any role secure seem obvious: keep it patched, remove unnecessary services, etc. But even those things are easier said than done, and it’s all too easy to forget a step.

Are you considering a SharePoint deployment? Or do you already have one that’s been running for a couple of years? Take a look at this list and let me know what you think.

First, some general considerations.

Are you using at least Windows Server 2003? Yes, I know there are tons of Windows 2000 (W2K) machines still in deployment, but that technology is just too old to keep reliably secure in the face of modern threats. A vigilant sysadmin can probably do so for an intranet-only server, but then again his or her time would be better spent on other things, so why not spring for the upgrade (or better yet, just get rid of the physical hardware, outsource the whole service, and hold the vendor to this list)? Definitely don’t use W2K for an internet-facing server.

If possible, the server should be fulfilling just a single role, i.e. serving SharePoint. Small shops will host the site and its database on a single server, which is fine. Big shops will separate those roles for scalability reasons.

Yes, many SharePoint deployments are based on Windows Small Business Server (SBS), in which case the server is performing lots of roles, has lots of services running, and lots of ports open. If that applies to you, refer to the other points herein and do your best. But know that if you’re running SBS 2003, which includes Windows SharePoint Services (WSS) 2.0, you can still deploy WSS 3.0 and gradually migrate your data (see this link). That’s generally advisable in order to take advantage of the higher security bar that Microsoft applies (usually) to each successive version of its products.

Regardless of which version of Windows you’re running, is it fully patched? Small shops should configure automatic updates. Big shops have the infrastructure to do pre-deployment testing of those patches. In my experience, if you’re running the most recent version of a web applications such as SharePoint, and running it on a single-role server, compatibility problems with “Patch Tuesday” are very rare.

Is SharePoint itself fully patched? Per my previous comments, you’re hopefully running the latest version. However, some scenarios, such as Team Foundation Server and SBS, have a dependency on WSS 2.0. In any case, ensure you’re running the latest service pack and patches for whichever major version you’re supporting.

Now to drill down a bit.

Is your SharePoint server running Terminal Services in application mode with NT4 security compatibility enabled? Check out this TechNet article. If you are, it’s essentially impossible to keep your server secure. Ditto if you’re not using NTFS, by the way.

Regarding IIS configuration, is a separate anonymous user (IUSR) account set for each virtual web site? That’s a good role separation and defense-in-depth measure.

Regarding the database, are you using SQL or MSDE? Smaller shops are probably using the latter, unless you installed SQL on the machine before installing WSS. In either case, be sure to check whether default passwords are still in use for the database.

Now onto specific SharePoint configuration considerations.

First, WSS exposes an administration website on a separate high TCP port (i.e. as opposed to the standard HTTP/80). This list applies to the admin port:

  1. The admin website should be configured to require server authentication (HTTPS/SSL/TLS). Otherwise, admin passwords may be traversing your network in plaintext.
  2. The Windows firewall, or a comparable product, should be enabled.
  3. The WSS admin port should be protected by a firewall rule which filters inbound traffic. Try to limit that number of workstations that can send traffic to that port, for example.
  4. The admin site should require Integrated Windows Authentication (IWA), that is, NTLM or Negotiate. Don’t use Basic authentication if you can avoid it, even if you’re protecting the channel with SSL.

What about the main SharePoint site itself? Well, speaking of SSL, similar considerations apply to the main site. After all, your users are likely uploading and downloading sensitive corporate information to and from WSS on a regular basis.

  1. At least allow HTTPS on the WSS user site. If the server load bears it, require HTTPS on that site.
  2. Use integrated auth on the main site (see above).

For internet-facing servers, has a special role been created to give Everyone browse access? This is a WSS administration best-practice.

On intranet-facing servers, has anonymous access been disabled? On the LAN, all clients should be required to connect via IWA.

Finally, here’s a list of potential issues cited for SharePoint v1. I haven’t confirmed whether they still apply - can anyone comment?

  1. Can users connect directly to the Search Proxy virtual server? They don’t need to be able to in order to have full functionality, so better to block it.
  2. Is the File System Object (FSO) enabled? It’s not required, so disabling it is a good measure to reduce the attack surface of potentially malicious scripts running on the server.
  3. Is the Windows Script Host enabled? See previous.

Other SharePoint security links:

Permalink | Comments (0)

I’m not so clueless as to think that I have any legitimate reason to sing the blues, but this post is really funny if, like me, you harbor secret dreams of having been born BB King in a parallel universe.

http://peaberryblue.blogspot.com/2008/04/how-to-sing-blues.html

Permalink | Comments (0)

I super excited that I’ll be presenting at CONFidence 2008 in Krakow, Poland next week (http://2008.confidence.org.pl/lang-pref/en/). This will be my first time there, and I’m honored!

Permalink | Comments (0)

“This American Life” (of National Public Radio fame) is running a great episode this week about the factors contributing to the current housing and credit crises (http://www.thisamericanlife.org/Radio_Episode.aspx?episode=355).

It’s impossible for me to do the segment justice, but suffice to say that they interview real people on both sides of the problem whose decisions, along with those of thousands of their peers, helped to bring about the foreclosures and credit crunch that are killing the US economy. I now understand.

Permalink | Comments (0)

A colleague forwarded this link - http://blogs.zdnet.com/Google/?p=1035 - about the new “Postini web filtering tool”. My initial reactions were twofold.

First, that Google now thinks it’s a managed-security services company … I just don’t understand. The company is like college freshmen - they’ll try anything once (at least). On the other hand, Google clearly has industry-leading expertise in managing information. But security services is a crowded market with big players, and Google has no pre-existing reputation in security. I doubt the margins will be like search; let me put it that way.

Second, the Postini solution, as described in that post (which is admittedly quite brief) claims the advantage of not requiring a VPN connection. At the surface, eliminating VPNs for remote access to a corporate network is a good goal, since they tend to be slow and expensive to support. The hitch is that most VPNs include robust authentication and encryption technology, and deploying an equally secure and functional alternative is at least as difficult.

My point is, if Postini isn’t using VPN, does that mean that all corporate data to be scanned is being sent in cleartext over the internet?

Permalink | Comments (0)

I’m attending the FBI Seattle Division’s Citizen’s Academy 2008. Highly recommended for anyone interested in the FBI and/or security. One recent briefing was about the Seattle FBI office’s work in retraining employees of the Puget Sound region’s banks in order to help catch bank robbers.

Now I’m sure warning bells are already going off in your head just reading that. Aren’t these people just going to get themselves shot?! That was my initial reaction as well. But these new techniques are deceptively simple, are reportedly already measurably successful, and I like the idea of fewer bank robbers running around.

As an aside, the agent who did the presentation is an enormously entertaining guy – the kind who could sell a ketchup popsicle to a lady in white gloves. And this is predominantly his hard work and research. You can see his picture in the news links below.

Any current or prospective bank robbers: pay close attention.

  • First, the Seattle area has a high rate of bank robberies, on a national level. A few reasons are cited for this, including that bank robbers in Seattle tend to be homeless and are frequently addicted to heroin. And this is a welcoming community for the homeless and for addicts.
  • Second, bank robbers tend to be serial offenders. They’ll do it 10, 20, whatever number of times until they’re caught. That’s an important consideration, because it means if you can catch the bad guy on the second offense, for example, you’ve helped a large number of potential victims downstream. You’ve had an exponential (positive) effect on your crime statistics.
  • Bank robbers tend to target female clerks, and particularly all-female banks (as in, you walk in the door, and all you see are women).
  • Next, cameras are mounted high, so robbers where hats and sunglasses.
  • The bad guys don’t typically go for a take-over; they act like a regular customer, and use a hand-written note (no weapon means less jail time) when they get to the teller counter.
  • After the job, time is a critical factor in getting police on the scene before the guy gets away. As little as 15 seconds is enough to make the difference.

So the new bank employee training scheme goes like this. First, if the teller sees anything potentially suspicious, such as a guy standing in line with a hat and sunglasses, she excuses herself from the current customer she’s helping and informs a greeter. Then she goes back to her customer.

The greeter, preferrably a man, has a desk away from the tellers. His job is basically high-intensity customer service. He goes up to the suspicious-looking person and says, “Hey, I don’t recognize you. Are you here to open an account?” “How can I help you?” Etc.

If the customer is a real customer, he gets a free pass at this point, since he just managed to jump the teller line and, in most cases, get helped by the greeter.

If the customer is a bad guy, the extra attention is most unwelcome. For one thing, he’s being drawn away from the teller counter, so the mechanics of his plan have been disrupted. And depending on his excuse for being there, the greeter is going to ask him for ID. That’s critical for the overall strategy, because it gives the bad guy an easy out: “Oh, my ID? I left it in the car. I’ll be right back.” He’s gone, disaster averted.

What if a note-passer does make it to the teller counter? For one thing, there’s a strategy about how much $$ to give. Too little, and you risk further confrontation. Too much, and you can bet he’ll be back to rob you again next time. Stack smaller bills under some big ones. And once the cash is on the counter, the teller takes a step back and puts her arms out to the side, signaling, ‘there’s your money - take it - we’re done, right?’

Once the bad guy is out the door, the teller who interacted with him is the one who calls 911 - immediately. Everyone else assumes strategic positions around the inside of the bank, looking outside, trying to identify the bad guy’s escape route and/or vehicle.

That last bit is a change from previous practice since, for one thing, banks use offsite security monitoring that’s frequently centralized and hence not located in the same town. The security company, once notified, had to first call the bank and speak to a manager to confirm what’s going on. Only then could they call the police, but not via 911 because they’re not local! And the security company has no idea what the bad guy looks like, which is pretty much the next thing that the police need to know in order to have a hope of catching the guy.

Finally, put the bank security cameras at a low angle so they can get good shots of people at the counters.

Local news links on this:

Permalink | Comments (1)

They’re offering up their articles to included in your next company newsletter. Could be a good way to bulk it up a bit.

http://usergroup.windowsitpro.com/generator/

Permalink | Comments (0)

Heh heh - looks like another error of omission in my OTP article in the latest MSDN: the sample code is compatible with the standards that form that basis of the OATH (as in, ‘open authentication’) OTP architecture.

For comparison, there’s a Java-based reference implementation (mine is C) included with this IETF draft.

Permalink | Comments (0)
Newer Posts »