If you haven't heard, PASS is running a contest where you could win conference registration to this year's PASS Community Summit or, if you have that covered, 4 nights coverage of hotel costs. All you have to do is enter by July 1. Check the link for details. Here's my best thing I learned, which was from the 2004 PASS Community Summit:
It was a packed, standing-room only presentation. The late Ken Henderson was talking on how SQL Server allocated memory, and was talking about the MemToLeave region. He discussed how large execution plans can tap memory from this space and how any such allocations require contiguous memory. So if MemToLeave is fragmented and you need a large amount of memory, a contiguous block may not be available, generating an error. I slotted away this knowledge, never thinking I would use it.
Fast forward a couple of years when one of our teams kept reporting that one of their nightly processes was failing with an error indicating that it couldn’t allocate contiguous memory. My mind went back to the Henderson talk. The error indicated it couldn’t allocate 229 MB of contiguous memory. When the default setup had only 256 MB total, it wasn’t surprising. Some were blaming SQL Server and asking a case be opened with Microsoft. I pointed to the amount of memory and asked what needed that much. We looked and found a horrendous query in a looping piece of code. It was being built dynamically, adding an AND clause to the WHERE each time it processed a record. This was to exclude said record and the process had tens of thousands of rows to process nightly. I can’t imagine what that execution plan looked like. We had a likely culprit and forced them to rewrite the process. After they did, the process didn’t fail again.
We had my organization's semi-annual combined IT and financial meeting this morning. At the end of these meetings awards and certifications are announced. I had earned an award but I wasn't recognized. I'm a bit disappointed, and I can understand why, but I also know that I shouldn't be. Oversights happen and the things I did to earn the award in question I did because I wanted to do them, not because of the award itself. I enjoyed doing those things and in my mind that should be reward enough. So I'm struggling with myself over the fact that I am disappointed.
To put things in perspective, I'm disappointed about not having my name called whereas the guy who was sitting next to me will likely have to pull an all-nighter to facilitate a customer migration to new servers. And this is after he was up working until 1 AM this morning prepping for the move that will happen tonight. Not only that guy, but two other guys I know will be working like crazy. With that sort of reference point, not having my name called is a really silly reason to be sad.
This got me to thinking about how often we let emotions drive us. Some emotion is good. We should feel passionate about what we are doing. I was passionate about doing those things which earned me the award in the first place. That's emotion. I think if we're using emotion to motivate us to do better, that's fine. But when emotion holds us back from our best, that's a different story entirely. I have had a little talk with myself about how it won't help to be disappointed and that if I were in the same position and there was no award, I still would have done those same things and enjoyed doing them.
It also made me realize that I do wish I had a local mentor to talk to, someone I could pull aside to help me see things in their proper perspective. I was able to see things as they are and make corrections, but that's not always going to happen. Andy Warren has written a lot on mentoring and it has spurred my thinking about the importance of mentors, especially lately. I think that's one thing great mentors are able to do: help folks see things in the proper perspective. In IT our work is so involved and it can consume us. So we can lost perspective on its importance in our life. Likewise, we can have situations like mine today. And we can react wrongly and let affect our actions, our mood, our life. There's no real reason to let that continue. But sometimes it really takes another person, someone we trust and someone we know who's looking to help us grow, to get that through our heads.
Early last week, my church suffered a lightning strike that did quite a bit of damage (relatively speaking) to computer and media equipment. I spent a lot of time last week during off hours working the issue along with some other very knowledgable folks. We're not out of the woods yet, but we were up and running and were able to cover a funeral last Friday and worship services on Sunday. In thinking about it all, it brought me back to business/disaster recovery. Since a church is a relatively simple model, I figured I would blog about it to hopefully stir some thoughts for more complex situations and conditions.
Understand What You Need and When You Need it By, Before the Disaster
This one should be self-explanatory, but I've seen cases where it has not been done. I'm the junior high youth pastor at my church and we're not very heavily computerized like some churches. So no one had really considered this thoroughly for us. We carry cell phones if members need to reach us. As long as we have a building with seating, we can hold most of the services we "provide." So our essential recovery is rather limited in scope. But if you're a business of any size, you need to do this before a disaster does hit. In our case we made a quick evaluation of what was critical for services. Getting all of our lighting back was essential. Sound and A/V for the funeral and services was most pressing after that. Establishing network connectivity, especially Internet connectivity for a couple of the systems followed. Everything else was after those key priorities.
Assess the Damage
After the lightning strike, one of the first things we needed to do was assess the damage. Actually, we took a slightly different approach, in that we assessed what "systems" didn't work. Knowing what is damaged tends to be a little trickier, because if you have multiple components/systems in-line, you've got to test 'em to determine what's actually broke. This is what we noted were down:
Once we knew what was down, we started looking at the component parts. For instance, not all the phones were down. So we took the ones that were and tried to connect them to the lines that were working. No dice. When we plugged them in to the power bricks that were working, they were dead. So we knew the phones themselves were history. With respect to networking, the DSL router was fried. It didn't even power up. We had another power cord that was known good with the same power characteristics and that didn't work. The DSL router was also a switch. So I grabbed a known good switch and tried to network the computers. No Internet, but access to printers and the like could be had... except that didn't work, either. I suspected the NICs on those computers, especially after one of the office computers didn't recognize its NIC any longer. However, another did recognize its NIC, but I couldn't get connectivity. I suspected the wiring, especially since I had one component I believe to be good not working when connected to the switch. In any case, you get the idea. We did this for all the components.
Have Your Insurance, Service Provider, and Hardware/Software Reselleres Contact Information Ready
Once we had determined there was some damage, one of the church staff placed a call to the insurance provider to verify the process for submitting a claim. Before we did anything with the equipment, we wanted to know how to proceed. We were able to get the information and start handling the equipment appropriately. The last thing we wanted to do was handle the equipment in such a way that the insurance company could say, "You violated subsection A of your agreement and we won't reimburse." We also contacted the DSL provider and had a new DSL router sent. Part of recovering from a disaster is filing the claims to be able to pay for equipment that has to be replaced. And part of it is understanding where you can get the replacement equipment.
Determine Work-Arounds
We had an action plan on how to proceed with recovering capabilities (we're still executing on it). In one case, the Internet connectivity, once we got the DSL router in, like most nowadays, it had wireless capability. Thankfully, though it looks like our phones/networking got hit by the lightning, once the new router came in, it was apparent that we still had DSL service. I was able to get that connected and running fairly quickly. However, since I'm almost positive the wiring is shot but I can't be sure about the NICs, we ran out and grabbed a couple of USB wireless NICs to install to provide some capability for Internet connectivity within the church. I knew there was a strong signal throughout the top floor because I did a walk around with a laptop and made sure of it. There are plenty of tools out there for this purpose. But a rather simple thing to do is walk around connected and just see if you can hit particular web sites. That's the low tech solution and it works just fine. Because I didn't have my normal security tools on this particular laptop, I went with the low tech option. The USB wireless NICs worked great and we had two systems on-line on the Internet.
Keep a Running List of Unresolved Issues and Reprioritize As Necessary
One of the applications we use for AV was built for two monitors. We were able to determine the second output of the video card had been damaged, which meant we were down to the single monitor. While the second monitor was good, we were able to verify the projector was hit, too. We had a spare projector, but no one had done the research on how to get the application running on a single monitor. We had temporarily used PowerPoint and hand-typed lyrics in, but we wanted to use the app because it handled this and handled it well. So after Sunday morning, we looked at where we were and noted that we still hadn't fully restored that capability. So before evening service we sat down and did that research. While running on a single monitor isn't ideal, it's do-able until we swap out the soundboard computer within the next week.
Determine What Can Be Done to Avoid the Disaster or Respond Better to It (Lessons Learned)
In our particular case, we had surge protectors and the like in place, but we're talking lightning here. Some of it was sufficient based on the exposure of the equipment, but some of it wasn't. We're looking at the building and seeing what else can be done, but there's only so much that can be done in this situation. That's one of the reasons it is smart to carry insurance. But if you have a failure, use it as an opportunity to learn. What could have been done to avoid the situation, if any? Is it reasonable for the business? What was done that could have been done better to recover? Were the recovery procedures satisfactory? Is there something else that needed to be done? Once you've looked at the situation, go back to your recovery plan and make the appropriate changes.
When the announcement for Bing came out, I didn't immediately go over and check it out. As a matter of fact, I didn't even look at it. My reasoning was simple: Google was working well and therefore I didn't see any reason to switch. But this past Saturday, Paul Nielsen of SQL Server Bible fame tweeted the following:
Microsoft search engine Bing honors D-Day on their front page. Goggle "honors" Tetris.
To me, D-Day is a bit more important in world history that Tetris. So I clicked over and saw an image of the beach and the land behind it, where Allied forces came ashore 65 years ago. You can still see the image if you go to the Bing page and hover towards the bottom right of the photo. You should get left and right arrows, which allow you to navigate back and forth to see the images that have been posted. The D-Day one was Saturday's. Imbedded in the image are a couple of highlights which can take you to more information on that fateful day.
Now the fact that Bing was honoring D-Day and Google wasn't isn't the reason I switched. However, the difference in their choices is the reason I considered Bing. I took a look at it, ran a couple of searches and was reasonably satisfied with what I got back. So since I was already there, I decided to configure it as my default search provider for both IE7 (sorry, I've not upgraded) and Firefox on my personal laptop. I figure I'll give it a run for a few weeks and see how it does. If I don't like the results, I'll switch back. If I do, I'll leave it alone. If it works great, I'll look at switching over my other systems, too. If you're interested in doing the same, you may want to visit the following link:
FAQ: How to add some Bing to your browser (ComputerWorld)
This one isn't a technical post, but it's entirely appropriate to those of us in the IT field. Today was a stark reminder about priorities and what they should be. Those who follow me on Twitter probably saw that I tweeted about a tragedy that affected one of the families in my church. In a nutshell, the unexpected did happen and someone did pass on fairly young. There's a lot of folks taking it pretty hard, my family included. One of the things I tweeted was the following:
A reminder that life can end unexpectedly. Live life to the fullest today and prepare fully for eternity now. There may not be a tomorrow.
If you aren't a person of faith, then the preparation for eternity part is taken care of, so far as you're concerned, but it is still important to live life to the fullest. That doesn't mean be foolish and careless and reckless. But it does mean looking at priorities and thinking about what's truly important. If something is important to you, it should get the proper amount of time, attention, and care based on its priority. For me, my priorities basically follow the pattern:
Sometimes these things go together. For instance, I love to play boardgames. So do my boys. And that's something we do together. But if I have to give time and effort, I will do so based on the previous list. Now there are always times where times will be slightly out of balance. For instance, if I have to work extra hours to complete a project, then it gets done. But over the last few years I've experienced that when you rob one priority to give time to a lesser priority, no one is happy and nothing gets done as well as it should.
As an IT professional the job / professional reputation is easiest to spend the most time on. If you like your craft (and I do), working with technology can be fascinatng and it can be easy to immerse, to the detriment of the other priorities. I've done it and regretted it after the fact. In the last two or three years I've worked very hard to correct that. I know others in the same boat who have done likewise. And the more we get our time and effort and care to match our priorities, the happier we are.
With that, I'll get off my soapbox. But if you haven't thought about what's really important to you, now might be the time to do so along with some self-evaluation to how your time and efforts match up with those priorities. I have found that regularly reassessing my time and effort has helped a lot in making sure I am giving the right emphasis where it needs to be. And I'm very glad to have started that practice in my own life.
When it comes to securing a system, it's important to understand how it might be attacked. That's what surface area is all about. The surface area is the parts of the system which are exposed. For instance, in the case of a default instance of SQL Server 2005 or 2008, we typically see two TCP ports open:
We also typically see the Shared Memory protocol enabled, meaning an attack is possible if you can get on the server itself. Since the DAC is certain limitations as to what can be run (but it also allows access to things that you can't get to with a normal connection), the connection using TCP/1433 or Shared Memory might be preferable. And in some cases we see Named Pipes on as well. If that's the case, this protocol can be used as well. All of this can be checked with the SQL Server Configuration Manager. And all of this is part of a SQL Server's surface area. If you're in charge of administering a SQL Server and you've never checked all of this out, there's no time like the present. And depending on what other features you have enabled, you might see more (such as a Service Broker or HTTP endpoint which exposes more TCP ports).
But what about once you establish a successful connection? What then? I've already mentioned Service Broker and HTTP endpoints, which can expose even more access to SQL Server. Within the context of SQL Server there is the ability to enable other features which increase the surface area. For instance, you can flag DAC so it's also available remotely. That means I don't have to compromise the server SQL Server is running on any longer to attempt to connect to the DAC. I can try and hit it remotely. You can allow certain features like OLE automation or access to xp_cmdshell, which are not normally accessible to any users, not even member of the sysadmin fixed server role (though they certainly have the capability of turning these on). It's important to know what features are on and which are off. In SQL Server 2005 there's SQL Server Surface Area Configuration (SAC) but in 2008 the tool is no longer present. Instead you've got to use Policy Management with the settings you care about. The advantage in 2008 is SQL Server can enforce these settings. SAC can read when you start it up and it can apply changes to settings, but it's not a continual monitoring type of tool. That's the reason 2008 uses Policy Management to maintain surface area configuration.
The point of all of this is to understand how an attacker might get into your system. the starting point is understanding the surface area: what's on and what's not. You need that to go to the next step, which is figuring out how an attacker might use an exposed interface or feature to attack said system. For instance, once I've determined that SQL Server is up on TCP 1433, how might the attacker go about using that? If there's a web server in the DMZ which connects to that SQL Server, then by compromising the web application I may be able to come in on that port. That's the attack. But since I know what's exposed and a potential attack, I can think of appropriate defenses. For instance, I can have IDS/IPS looking at the network traffic for certain key things where that web server talks to that SQL Server on TCP 1433. If I see xp_cmdshell, I know that's not right. And I can flag it and do something about it. But it all starts with me understanding the surface area.
Whenever I do a security presentation, I make sure to cover the Principle of Least Privilege. And when I do I boil it down to this very simple definition:
Giving the rights to do the job. No more. No less.
If you don't give enough rights, the person can't do the job. Obviously that doesn't work. And the whole point of the Principle of Least Privilege is to ensure too many rights aren't given out. After all, a user could do something unexpectedly and because of the additional rights cause damage he or she shouldn't. Or the user's account could be compromised and the attacker uses those additional rights in a bad, bad way.
Okay, all that's logical. So how to determine what rights are needed? I've seen a lot of folks start by saying, "No!" and then making folks prove they need the rights. That's the quick and easy way, for the person "signing off" on said rights. It's also the lazy and least productive way, IMHO. I saw a tweet today by a DBA who was facing that issue with management. I tend to take a different approach. Here's what I do:
I approach it not from the "You must justify it" side but rather the "What do you need to do it" one. That makes it an interactive process where both parties are working to ensure security is taken seriously, minimal effort is expended overall for the organization, and the correct solution goes into place the first time. So what happens if you have the "You must justify it" person? I approach that situation like so:
And that usually does the trick. If they still say, "No," and then I'm not able to do something expected of me, I have the documentation to explain why i can't do my job and the evidence that shows I communicated the need for those rights. After being burned once or twice, usually they'll go back and grant all the rights I said I needed. And next time they are less likely to question my assessment.
On a couple of recent webcasts, I pointed out the folks were running with the local Administrator account. To start this out, I'm not a big fan of security by obfuscation. Security by obfuscation (not code obfuscation, but security by obscurity, if you prefer, I'm using the terms obfuscation/obscurity interchangeably in this sense) is where you hide something and hope no one finds it. For instance, you move the port of your web server from port 80 to another port, thinking you're safe. You aren't, as anyone with nmap or another port scanning tool can find your web server. But when it comes to the Administrator account, I prefer to rename it. The reason is fairly simple: you know that scripts, worms, etc., will target the administrator account and by renaming it, you immediately stop those attacks in their tracks. Sure, you'll get the hits in your security event log, but that particular account has no chance of being compromised by such attacks. Yes, the SID is well known, but to identify the right account requires a bit more sophistication in the attack.
Now I must admit, in the cases where I saw the use of Administrator, the presenters were running in a VM with no sensitive data on board. And given that it's not exactly hard to locate the Administrator account, why say anything? It goes back to something I believe Steve Jones said a while back. Basically it amounted to, "Don't tell me not to do something and then do it." If I remember right, he was speaking with regards to presentations. Part of the point is that people will remember what you did. And if you're a parent, you understand that "Do as I say, not as I do," doesn't work so well with kids. I don't think it works very well with anyone.
So the issue is someone who doesn't know better will see the presentation and either not hear or not remember the warning, if one is given. And they see the presenter running as Administrator and maybe the next time they do something, they do so, too. They're in charge of administering a server that doesn't have the administrator account renamed. And they don't think twice about it. Or they've got their own presentation and they repeat the behavior, not seeing it as a big deal because so-and-so did it, so it must not be that important. And a bad practice gets repeated and passed on.
But what about a different account, one that is a member of the Administrators group, just not named Administrator (even the renamed Administrator account itself)? I know there's a lot of folks who say this is a no-no, too. But there are still some key tools (Visual Studio 2005, for instance) that require administrator level privileges. With Vista, UAC gives you some protection, provided you leave it on. Also, with Vista Internet Explorer can (and should) be run with Protected Mode on and with Firefox you can use plug-ins like AdBlock Plus and NoScript to provide additional protection. So I'm not one of those who has as big an issue with that. I still don't like end users with Administrator level privileges, but when it comes to developers, system administrators, and DBAs, a lot of the tools we use just don't give us much of a choice. So it's something we live in and just try to be "smarter tha the average bear (to quote Yogi the Bear).
I was playing around with the endpoint catalog views this afternoon just looking at ways to do poor man's configuration collection on SQL Server and the options avaliable. The endpoints naturally represent the way in to SQL Server and since TCP is the default network protocol for SQL Server 2005 and 2008, I was looking specifically at sys.tcp_endpoints. Basically, I was looking to execute the following:
SELECT [name] , [state_desc] , [port] , [is_dynamic_port] , [ip_address] FROM sys.[tcp_endpoints];
This query would seem to return a lot of useful information. It returns the name of the TCP endpoint, whether or not it's active, what IP address and port it is listening on, as well as whether or not that port was configured dynamically. However, what I got back was 0 for port, 1 for is_dynamic_port, and NULL for ip_address for several servers I hit. basically, these are the three columns in sys.tcp_endpoints that are not in the catalog view sys.endpoints. They represent TCP specific configuration information. But with one glance it's obvious that the information being returned isn't useable. So I went back to Books Online and checked, and sure enough, there was this proviso:
The information that is displayed regarding ports and IP addresses is not used to configure the protocols and may not match the actual protocol configuration. To view and configure protocols, use SQL Server Configuration Manager.
So if you're looking at trying to extract the IP address and port SQL Server is listening on from this catalog view, don't. It can't be relied upon. The guidance from Books Online says to use SQL Server Configuration Manager and that certainly works, but it's a GUI tool, and not useful for retrieving the information using an automated process. All of the information on TCP endpoints is in the registry, it's just a matter of parsing the information out. So I'll be looking at writing a quick script that does just that.
Tomorrow night, May 28th, I'll be speaking the Augusta Developer's Guild. This is a make-up from earlier in the year when I got sick. Feeling just fine and looking forward to talking about SQL Server and security. If you're in the area, please come on by. I'd love to meet you!
Yesterday I did something I wouldn't have thought of doing a year ago: I stayed home. When I woke up, my sinuses were pressing down so hard that it hurt to move my head. Sometimes, a nice hot shower will help open things up and I'll be fine. Combine that with some over-the-counter medicine and I'm good to go. After that shower and medicine, I still felt no better. So I made the conscious decision to stay home.What spurred me to stay home? Only several articles I've come across in the last year which have really pointed out sick workers may be doing more harm than good for their organizations. For instance:
I know when my sinuses get like they were yesterday, if I don't slow down the problem persists. So while I may be at work, I'm not very effective. Also, I tend to be more prone to migraines, which, when extremely powerful, render me totally ineffective. It's something I've known for a while, but I never thought about the cost of that feeling bad lingering from day to day versus resting for a day and then going back to work refreshed and better. And as I looked at the situation, I realized that I was better off and more productive if I just chalked up the initial day as a sick day and came back in better health the next. I didn't used to be this way.
Last year this time I would have come to work and slogged on through it. The idea that missing a day in an unplanned manner was bad for business was the only thing I considered. I didn't consider decreased productivity while I was sick or the fact that the condition lingered causing a prolonged episode of decreased productivity along with a greater chance of another illness later on. I only looked at the immediate. Or I would have logged on from remote and spent the whole day staring at the computer screen attempting to work from remote when I needed to be resting and recovering. I know better now.
Take yesterday, for instance. Only one pressing thing came through and that was first thing in the morning. I was able to take care of it as I was setting up my out of office status and reporting that I was taking a sick day to my team. After that, I signed off and went to bed. Today I'm refreshed and rearing to go, ready to make progress on a few tasks I have before me. I can't really see myself doing a good job on them yesterday even though I would have given my best. And if I hadn't taken the time off, I would figure myself to be in about the same shape today. So naturally, I know I made the right decision.
Note: Since there have been several comments on this, I'm using parameterization at the application layer in the security sense of using the CreateParameter method. I'm not talking about parameterized queries with respect to execution plans or the specific use of sp_executesql. I thought I made that clear with me saying "proper parameterization at the application layer" but since there have been several comments on that, it must not be.
One of the main defenses touted against SQL injection attacks is to use proper parameterization at the application layer. But while this gets most of the cases, there are clearly examples where this alone fails. For instance, consider the stored procedure:
CREATE PROC dbo.usp_ExecuteSQL @SQL NVARCHAR(4000) AS BEGIN EXEC(@SQL); END;
Now I know the natural response by most folks is, "I would never see that in a production application." Perhaps not. But I have. In one organization's main application I found this procedure not once, but twice (albeit with different names). There was a standard in place that all database access from the application had to be done through stored procedures. The standard was met. But naturally because of such access, you can imagine what the permissions looked like within the database. And you can imagine the abuse that could have been performed through these types of stored procedures.
I know this is an extreme example, but it reflects that just focusing on parameterization isn't enough. For this stored procedure, the parameter would be defined properly, but that wouldn't stop SQL code from running in the back-end. Now I know the argument is, "Well, it's because the stored procedure used dynamic SQL." True enough. However, there are lots of cases out there where dynamic SQL solutions are running in production. For instance, I've seen things like the following:
USE [AdventureWorks2008]; GO CREATE PROC dbo.usp_ReturnPeople @Sort NVARCHAR(100) WITH EXECUTE AS SELF AS BEGIN DECLARE @SQL NVARCHAR(MAX); SET @SQL = 'SELECT Title, FirstName, MiddleName, LastName, Suffix FROM person.Person ORDER BY ' + @Sort; EXEC (@SQL); END
This stored procedure falls prey to situations like where @Sort can be sent in as '1;DELETE FROM person.Person;' which would effectively delete all the data in that table. And since @Sort would pass the parameterization check, using parameters doesn't serve as an effective control to prevent the SQL injection. Now I know there are techniques involving XML or using the CASE statement in the ORDER BY clause, but these aren't immediately obvious. As a result, it is possible to see an example like I've given above than those solutions. And yes, one could pare down the size of the parameter and that would help greatly, but when folks are trying to be flexible, these things aren't necessarily on their radar. Nor would a consideration be made to use EXECUTE AS with a defined user account that only has SELECT permissions against the table. And unless there is stringent code review, these types of things may slip into production and once they are there, they have to stay there until there is time to do another build.
Therefore, if we rely strictly on parameterization as our defense, we can still be beaten, even without someone working maliciously on the back-end code. Both examples I've given were written by well-meaning people who were trying to develop a reasonable solution. And the solutions they came up with solved their problems and they moved on. They didn't consider the security ramifications. Maybe they weren't aware enough to them to code defensively against them. Or maybe they were under a stringent deadline and were trying to get the job done. Whatever the situation, the vulnerability is there. So how do we guard against that sort of thing? Two things come to mind:
Now none of this is new. In fact, David Litchfield talked about second order SQL injection attacks at BlueHat and has published work on lateral SQL injection attacks in Oracle. The crux of all of this is to say there isn't one single vaccine to cure SQL injection. Parameterization is effective, yes, but a cure all it's not. There can be structures in the database that permit SQL injection attacks despite parameterization. And therefore, we must not stop at just using parameterization, but we must investigate further to ensure that we catch those vulnerabilities.
This is spurred on by a comment a pen tester made. He was referring to a particular technology and said something to the effect of, "What do you expect? It's 30 year-old technology." I was stunned when the comment was relayed to me. My response was, "An armed guard with an M16 can be an effective control. And the M16 has been around since the 1960s. And that's 40 year-old technology." The point is that the age of a technology or control is not all the most relevant factor. What is relevant is whether or not the control is effective. A similar corollary is it doesn't matter how expensive the control is, it still boils down to whether or not the control is effective.
A good example I can think of is at a military base I once visited. The base had gates with armed security personnel. However, unless there was a reason to suspect a threat (and where this base was located, it wasn't very likely), the weapons were holstered and unloaded. The base had no means of preventing a car from turning onto the road that ran through the middle of the base and driving right by the main gate. So if someone wanted to get onto the base, that gate was not an effective control. Even if the security forces were armed, if someone turned onto the road to the gate, they could build up a good rate of speed before reaching the gate. You can draw the obvious conclusions as to how effective the gate was in that situation. Now, at the time I visited, the world was a kinder, gentler place. Also, as I pointed out, there wasn't likely a threat to the base. The gate was there to ensure the merely curious stayed out and to catch military personnel who might have gone out on the town, imbibed a bit too much, and decided to drive back to the barracks or base housing. Those were bigger risks.
Then there is this:
These "dragon's teeth" were part of the Siegfried Line and were reinforced concrete pyramids that were designed to make driving a tank through a very risky proposition. Low-tech, reasonably inexpensive, and based on older technology, but they were an effective control at that time.
And that's what it really boils down with respect to a control. Does it protect against the threat it was put in place to guard against? If the answer is yes, then it doesn't matter how old it is or how cheap it is. Similarly, if the answer is no, then it doesn't matter how new it is or how much money was spent on it.
Shortly after the Zune debuted, I purchased one. And I've been happy with it. It's done everything I expected out of a music/video player and it's gone with me nearly everywhere. So I was a bit saddened to pull it out this morning and see that the screen had been cracked. Not the external glass, but the internal LED screen. It's been a few days since I've used it. I believe the last time was right before SQL Saturday in Atlanta. It had gotten tossed in one of my laptop bags, one with plenty of padding, but it looks like a sharp impact to the screen still occured. I'm not sure if it occurred while it was in that bag or some other time. Though it still plays, I can't read a single thing on the screen, renduring the Zune unusable.
This morning I thought about what to replace it with and got a few bits of feedback from some folks on Twitter and on Facebook, but it'll be probably a month or so before I do replace it. There's a very good reason for the delay: it's not budgeted and I don't have money saved up for its purchase. The excess money we had saved up went towards a planned purchase of a MacBook about two weeks ago. In considering how I've used it over the last few months, I've realized that it's not essential for me to have a new Zune or iPod or other mp3 player. I have a PSP which mostly collects dust and for the purposes of carrying portable music and some podcasts, it'll do. I could go ahead and purchase a new player and throw it on a credit card, but like I say, it's not budgeted and the money hasn't been saved up and set aside for it. Purchasing on credit is not something I want to do for something that isn't absolutely essential.
This got me to thinking about projects and resources and how they get allocated. We all what resources and focus on the things we care about the most. For me, that has usually been the security side of things and now it's ensuring that we get good code that performs well against the databases I support. But there are a lot of things that need to be done to bring a project to completion and sometimes you have to compromise in certain areas to get to the finish line. This means sometimes not having the resources to crank every bit of performance out of each and every stored procedure and data access code. Often the resources that would do that are busy working on bugfixes or supporting the implementation of those bugfixes. And that means that stored procedure code base which is performing okay is left at performing just okay.
When I have served as a project manager, I have understood this dynamic and accepted it. It's part of the trade-offs you have to make to ensure resources are assigned to the proper areas to complete the project. But as a technician I've realized sometimes that I have a very myopic view of an application or project. Of course I want the stuff that's important to me fixed first. However, in the grand scheme of things those things may not be of the highest priority. But I'm only seeing the things that impact me. I'm not taking a step back and getting the bigger picture. And sometimes I've made a big deal out of it. And some of those times the PM doesn't take the step back either and assigns the resources to my priorities when he or she shouldn't. It's the same as buying a new mp3 player on credit.
As technicians, when there isn't enough resources available to complete all the wants for a project, it's time for us to take a step back. We need to try and understand where our needs fall within the other needs of the project. Does our needs truly deserve priority? If they do, then we should detail why in very clear language that explains the impact of not getting to what we want to see accomplished. There is a great temptation to exaggerate a bit, but that doesn't serve us well. We may get priority on this project, but what about the next one? If we've exaggerated the impact and that is seen, then the assumption is going to be that we always exaggerate our issues. We'll become like The Boy Who Cried Wolf. And that story didn't end well.
Maybe our issues don't get resolved by the end of the project. But if they are legitimate and we've documented them well, then our organization knows about them. Hopefully they don't get forgotten about. If our write-ups were well done and the project had the right visibility, they won't be forgotten. And they'll eventually get the resources needed to solve the issues, if those issues show themselves to be painful enough. That's like saving up and buying the mp3 player when the resources are available. We don't overextend the organization or burn credit we shouldn't for something that isn't absolutely critical. All around, it's the smarter choice.
Not too long ago the developer community got a fantastic resource called Stack Overflow. It's a question and answer site, so it's like forums, only it's not. The interface is well done, finding questions to answer is easy because of the tag system, and the site has in place a capability to give people who are active more and more capabilities to help manage the site. It's a really neat idea. The issue with Stack Overflow is it is development-centric and by design. So the powers over Stack Overflow have created a sister site called Server Fault which is for IT professionals - Same interface, same tags, and same increasing ability to help be responsible for the community site.
Now Server Fault is currently in "private" beta, but that should last only a week or two based on the post about Server Fault in the Stack Overflow blog. If you've been somewhat active on Stack Overflow, check out that blog post, because it tells you how you can get active on Server Fault right now. It is actively being used. If you don't meet the criteria, don't worry, one or two weeks go by fast.
Does this replace technology centric sites like SQL Server Central? Not really, it's just another resource. The great thing about SQL Server Central is it covers all things SQL Server. So there are a lot of great SQL Server pros at SSC and at SSC you don't have to worry about going to a different site if you have a programming question or a system administration/SQL Server administration type of question. SSC covers it all with respect to SQL Server. And you'll see a lot of us on both sites. I'm a bit more active on Server Fault right now only because I'm trying to stay ahead of Brent Ozar on reputation and to get a chance to answer some questions there. Brent is a question hawk who will snatch out your prey right from under you! If you post there on a subject related to SQL Server, SANs, or virtualization, do it quick and do it thorough, lest Brent swoop down from on high! Okay, I'm kidding about that. When he's on, he's just trying to help, just like the rest of us, and he has a very great in-depth knowledge of multiple technologies. He also helps support the actual Stack Overflow site as their DB performance expert.
