The Downtown Boston .Net User group is having it’s first meeting tomorrow night. In a coordinated effort with the Boston .Net User group that regularly meets outside Boston in the Microsoft Office in Waltham, MA, Sam Gentile is hosting a downtown version for those that find it hard to escape the traffic.
Tomorrow night Sam is starting things off with his CLR Internals session which from all reports is a must attend!
Full details are best found here.
I have recently been asked by a deeply knowledgable friend of mine, Malek Kemmou, about the latest in Intrusion Detection software. I realized that if he was curious, then this might be a topic worthy of a few words…
The bad news is that there is not much out there really that can serve as a silver bullet. Alot like the Anti-spam software when it first started coming out, there were alot of players, but they all used the same basic technique. In the case of detection software we are in much the same place. Hackers leave footprints if you are logging (both on the OS itself and on the web server). If the logs are not configured or configured incorrectly then it is like having video cameras without film, they won’t help you solve the crime.
A further problem is that more elite hackers tend to alter the logs after they are done (wiping the gun clean so to speak). Step 3 (step 1 is to turn on logging, step 2 is to configure it appropriately) is to secure the logs from being altered (or dumped) by an intruder.
Products like GFI LanGuard will publish white papers (see the link) on why they are the best, but mostly they are the same. You could interpret most logs yourself until they get beyond a certain size.
You can even just submit your logs to DShield.org (been around since Nov 2000) and they will analyze them for you. Some interesting statistics come out of looking at the data from so many firewalls and web servers. If you go there note that they are currently reporting Survival Times of 22 minutes (The “Survival Time” is the average time between attacks for our average submitter. An unpatched PC will survive about that long before it will be infected with the worm of the day).
Here is a nice little article from the guys at Foundstone, http://secinf.net/info/misc/tricks.html, that should give you some tips on what you (and the detection software) should look for beyond the obvious “cmd.exe” in your standard IIS logs.
If you are using something you like, let me know, I expect this space to get pretty heated in the next 18 months as awareness rises and drives demand.
There was a time when I believed that I could keep a server secure enough that I could get away with not putting it behind a firewall. This used to entail just having a security plan and minimizing the attack surface. Then it got harder and harder to keep up. I held out for as long as I could, but sometime in the last year I got to the point where I won’t put anything I care about directly on the Internet. The Internet has experienced what seems like the fastest neighborhood slide in history!
This may seem obvious, but the important point here is the progression toward this point. Where next? Will we be taking things like smartcards for granted the way firewalls are now?
Security is a game that evolves, if you can get ahead of the next evolutionary turn you can prevent unpleasant surprises.
What do you think will be taken for granted in 18 months relative to security?
went well, except for the 7 hour drive to get there that should have been 3.5!
OK, back to the intent which is technology entry… I spoke on Sharepoint Programming and the crowd was varied (never heard of SharePoint to SharePoint guru), but engaged.
Single Sign On was the big thing since it has such potential to be misused. What if someone wires up Single Sign On for a backend system using an over endowed account and then provides a web part that is unconstrained in its actions? Same answer for all these kinds of questions, you die!
I am actually heading back toward New England now (aircard is such a great tool) so that we can make it back for an earlyish meeting back at the office tomorrow.
Back to Security postings tomorrow if I stay on plan.
Jeopardy Answer: What are 3 things that don’t go together easily!
If you feel the need to host ASP.Net on a windows domain controller and can’t bring yourself to upgrade to version 1.1 then at least read this KB article. The crux of the problem is that domain controllers on IIS 5.0 servers (i.e. on Windows 2000) don’t have local accounts for the ASPNet_WP.exe process to run under. You have to create your own weak account or assign more privileged accounts (bad idea).
I heard as recently as tonight about someone fighting this issue (it is always tough when the solutions are all security tradeoffs to some extent), but reportedly with .Net 1.1 (we are verifying). As a rule I don’t put ASP.Net apps on domain controllers, maybe that is just a rule we should all accept if we don’t like the other options presented?
Alot of sources say that you should rename your administrator account on your windows systems and windows network. While I agree with this wholeheartedly, you need to take the war to the hacker.
First, renaming the administrator account to admin or adm or something equally obvious when seen doesn’t cut it. You need to get evil. If you rename the account (and you should) then rename it to something indistinguishable from the rest of your accounts. Remember that internal threats are real and your uses can usually see the entire user list. Pick someone you went to school with that will never work for your company (at least not while you work there) and rename the administrator as if it were that person’s account according to your standard naming practices. SJones for instance for Susan Jones. Also fill out the record with a description, etc. For larger companies you want to make this impossible to discern by a typical user from someone working in a remote office or maybe a temp that never got deleted. Understand that this is easiest when you first setup the machine or network, but can be done long after if you can bring yourself to do away with using the Administrator account for services or regular network maintenance.
So now you have an administrator that no one can identify from just looking at the user list. The SID for the administrator account is still the same and we can’t do much about that, but we take what we can get.
Next move is to create a new account named Administrator. Give it a nightmare password (14 or more characters with mixed case and symbols everywhere) and then turn on auditing for failed logins at a minimum. Now you have setup a scenario where no one has any business using the administrator account for anything except hacking.
If you follow this tactic for all privileged accounts so that Exchange runs under MKelly and SQL Server runs as PRobinson then you have just taken a lesson from Sun Tzu and applied it to your system security. Machiavelli would be proud!
More than a year ago, I spent a day or two wading through WSE 1.0 (hence the title) to prepare a nice demo for a talk on GXA that Andrew Brust and I did at CeBit held in NYC. In my travels, I reviewed Tim Ewald’s white paper called “Programming with Web Services Enhancements 1.0” and soon thereafter I found a wonderful resource courtesy of Dan Wahlin at http://www.xmlforasp.net/codeSection.aspx?csID=81. Dan has put together a streaming demo that I classify as the moral equivelent of a WSE Hello World (I mean that in a good way in case you miss my meaning). I consider Don Box’s “Understanding GXA” the primer that the above resources really compliment if you want to know from a developer’s perspective what the deal is with WSE.
I often get asked how a developer can go about getting security savvy. Understanding the concepts of WSE is an important stop along the way.
I haven’t seen a valid link to “Understanding GXA” lately. You will have to settle for the latest found at http://msdn.microsoft.com/webservices/building/wse/default.aspx.
I have been considering starting to blog for a long time. There were false starts and pronouncements that I would begin that were left unfulfilled. As I write this first entry I realize that I picked the correct name for this journal – Tech Siege. The reason is that since before I left the military I have been trying to grok it all. The more I assimilated the more I realized I was clueless. I have a family and non-technical interests, but I find them shunted to the side often as I pursue that next concept that will finally round out my knowledge.
So with luck this blog will help me (and you maybe) focus on striking the balance. I don’t expect to be gushing very often about non-technical topics, but I assume they will slip in without my being lynched. If I do it right then I will learn as much (if not more) than anyone else who reads here. Isn’t it true that when we look at code we wrote last year, that is when we realize how we have grown as a developer.
Computer Security will be a common theme and that allows for mammoth tangents. We will see how it goes, only time will tell.