On Tue, 1 Mar 2005 17:24:25 -0500, Adrocknaphobia <[EMAIL PROTECTED]> wrote: > IMO if you are so serious about security you should a) put your DB > servers on their own network with a firewall between them everything > else and b) use Oracle.
I totally am in agreement with (a) -- mutlilayered security is much more robust than a single layer, though it's more of a PITA. That's the normal security tradeoff -- pain, annoyance, and inconvenience seems to be directly (or possibly exponentially) related to security. I think (b) is a less clear-cut. If you've got an experienced Oracle DBA (which is a virtual requirement for a serious Oracle installation) then you're in good shape. One problem w/ MS-SQL is that (like many Microsoft products) it's "easy" to set up -- securing it is a different animal altogether. Thankfully, MS made the default install of IIS6 more secure, has created tools like the MSBA to help evaluate SQL Server installations, and published whitepapers on how to secure the default install which even a non-CISSP, non-MS-SQL DBA should be able to follow. And since we've been pounding on MS-SQL, let's be fair and mention the default configuration out of the box for MySQL. Argghh! > Contracting a virus or having your server turned into a porn FTP > server are the least of concerns in the corporate world. Worst case > scenario there is a temporary loss of service until the servers can be > rebuilt. Depends on where your business value resides. If you provide content to libraries and you're suddenly serving porn instead of your collection of translated work of Aristotle, your business is being damaged fairly severely, regardless of the downtime to switch over to your redundant backup site (or rebuild the box -- whichever). Loosing a worm on the corporate network that affects your internal database servers that are not even connected to the internet, well that's just bad too -- especially if you're running something like Great Plains or Soloman internally... Of course then there's the downtime of the corporate systems to *install* the patches in the first place. Rock, hard place. > The primary concern should be in preventing hack attempts where > private information and trade secrets can be stolen. This is where the > result can cost the company money. These vulnerabilities reside in the > applications themselves. Your firewall will do little to prevent this. And now we're in a whole different type of security discussion -- and a more valuable one. Firewalls are simply one layer in a multilayer defense. SQL injection attacks can cause serious damage and are one of the best examples in the CF world of application-oriented (and far to common, yet generally easily preventable) security vulnerabilities. > Even if someone broke in to our datacenter, and managed to log on as > an administrator to our web servers or database server, they could do > nothing more because the applications themselves are secure. Without starting another long thread about it, if someone is in your data center you've got problems. If they are after your data and have *physical* access there's always a chance they can get your data, assuming they are willing to spend the money on it. Just like physical security, data security is all about making the cost of getting the data more than the data is worth. Sounds like you're doing a fine job. > Application security is the cornerstone of information security. Not > firewalls and routers. No doubt. But for multi-tier web applications, the security of each individual application, from the OS right up through the code your developers are writing is part of the "application" that needs to be secured. Many of the most common vulnerabilities that I've seen exploited happen at the interface between two tiers or applications, which is exactly why a CF developer needs to be at least vaguely aware of MS-SQL security issues (e.g. does the "user" the application runs as *really* need to be dbo?) for example. All a firewall does is prevent socket connections; all a router does is route packets (ok, many of these devices are now multifunction, but that's an aside). Layer 5-7 "firewalls" actual do some more interesting work to protect your *application* but in any case its all about controlling which packets get to the box. Securing the allowed behavior of packets that reach the application is another issue entirely... > > On Tue, 1 Mar 2005 16:52:40 -0500, John Paul Ashenfelter > <[EMAIL PROTECTED]> wrote: > > On Tue, 1 Mar 2005 20:53:13 -0000, Robertson-Ravo, Neil (RX) > > <[EMAIL PROTECTED]> wrote: > > > I would say NONE - all of the SQL boxes we have (and we have thousands) > > > are > > > a) protected with hardware and software security. They are all patched to > > > the highest degree (where needs be, as not all servers require all patches > > > for loopholes and indeed some cannot have them). > > > > Great! So by hardware and software security I'll take a stab at > > translating that as at least a firewall. So far we're in agreement. > > Remember, this started b/c I said anyone who left port 1433 open was > > an idiot -- now we're into discussing how to assess the risk from a > > specific vulnerability (choosing which patches to apply) and which > > service pack which *are* (potentially) past the normal desktop user's > > area of responsibility. > > > > > Let me ask you, what version of SQL are you running? 8.00.818? > > > > Actually, yes I am on my production servers. My clients are a mix of > > ..818 (post-SP3 hotfix) and .760 (SP3). And to be completely fair, my > > laptop actually runs 8.00.760 (with Named Pipes disabled). > > > > > Note you do not have to patch all risks if the risk is low - for example > > > there may be an issue where a maliscious user could access your server but > > > its only a problem/issue if the maliscious user can gain access to it... > > > > Agreed -- whether it's MS-SQL or Windows (or Linux or CF or whatever) > > you don't have to immediately apply patches if you're not vulnerable > > to the issue. As I've said, I run my laptop in *horrors* SP3 instead > > of the post-SP3 hotfix -- upgrading wasn't worth the risk (though when > > I build a new box, it goes to .818 by default) > > > > > > -- > > John Paul Ashenfelter > > CTO/Transitionpoint > > (blog) http://www.ashenfelter.com > > (email) [EMAIL PROTECTED] > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:197058 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
