Featured Article(s)
Using Http Compression through IIS
HTTP compression is a technique that can be used to reduce the network bandwidth to a large extent and improve performance. Even if there are downsides to suing it, it terms of CPU and Memory load in the server, they are negligible and wouldn’t be much of a concern. HTTP compression is actually an in-built feature available in the most popular web servers and web browsers available today. Generally, GZip or deflate modules are used to compress the data, most of the modern day browsers have in-built support for parsing GZip and deflate content. And, you need not do any configuration at the client side too! This article takes a look at how we can use HttpCompression in IIS and also discusses some related issues.
30 Sessions 11 Speakers, All Technical Content
(Direct to your desktop!) It the SSWUG.ORG SQL Server Virtual Conference. This is NOT a virtual conference like the "other guys" do – this is real content, real sessions, real speakers and real interaction with speakers, exhibitors and a lot more. All without leaving your office. No travel expenses, no time away. Watch sessions on-demand after their initial time slot and a LOT more. All, for only $100. (Not a typo). Get more information here.
Microsoft’s IIS "Under Attack"
Microsoft’s IIS is currently being exploited – and this relates directly to you if you’re using IIS and SQL Server. There’s a lot of debate about this – and whether it’s a new thing, an old thing being re-abused or something in-between. I suspect you’ll see a good deal of controversy about this – and for the SQL Server stuff, it’s not really new news. This really all comes down to SQL Injection. An important thing to know – I didn’t say SQL *SERVER* Injection. It’s a SQL thing, not a SQL Server thing. It’s also not really an IIS thing in this case. Injection can be done anywhere where user input is passed direction to the database server for execution.
I have to say, I’m with Aaron Bertrand on this one. This is not a new type of attack, and yes they deserve your attention, but they’re really just replays of the existing themes of unprotected servers running unprotected processes and hoping the site doesn’t get caught. To assume a malicious person or two won’t find your site and start beating on it to test it out is simply irresponsible. Much like sticking your head in the sand, you’re still exposed.
If you’re not specifically coding to protect access to your servers, not setting up permissions to protect things, and not using other steps (stored procedures, parameters, etc.) to control access, you need to understand these techniques – both from the hack side and from the protection side. There are a lot of resources out there – just search SSWUG on SQL Server Injection and you’ll be on your way.
Risk Management and The Costs of NOT Managing Data
Saw this really interesting article in Information Week about the changing roles associated with protecting information in different companies. It’s a good read overall, but what really caught my eye was information about the cost of data breaches.
The premise is that the cost is going up – 2005 it was $138, 2006 it was $182 and 2007 it was $197. Each of these is PER RECORD. The article goes into the differing roles and positions companies are establishing and also goes into different technologies that have been tried both now and in the past and how they’ve stood up to the tests of time.
Featured White Paper(s)
SQL Server 2005: Deployments and Tests in an iSCSI SAN
iSCSI SANs offer an alternative for building Storage Area Networks. Consolidating storage in a SAN offers storage management … (read more)
MS SQL Server – An Overview
Whether you’re running a small business that’s ready to take the next step in its growth or an SMB that’s ready to “grow into… (read more)