I wasn't necessarily recommending this approach. I was pointing out that if the current state of affairs is not desirable, then there are other ways to address it. (And those ways are not trivial.)
This is without any other information about what the data is or how it is "sensitive". As for encryption, it should be considered for things that are deemed "sensitive". *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> *Exploiting Technology for Business Advantage...* * * On Thu, Oct 7, 2010 at 4:15 PM, Brian Desmond <[email protected]>wrote: > *You’re assuming that the app has no other network dependencies. You also > need to at this point turn on SQL Auth on the DB which is not the default > and not technically best practice. Further you still have the app pool > running as network service which means it has the access a computer account > has in the case of one of the OP’s scenarios.* > > * * > > *Encryption is pretty subjective. For all we know the OP’s app is > returning yesterday’s weather from a database.* > > * * > > *Thanks,* > > *Brian Desmond* > > *[email protected]* > > * * > > *c - 312.731.3132* > > * * > > * * > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Thursday, October 07, 2010 8:44 PM > > *To:* NT System Admin Issues > *Subject:* Re: Need System/Application Security Advice > > > > What you're asking for is a redesign > > > > One way to address this issue is the place authentication in the hands of > your database tier, and not grant any special domain level rights to IIS. > This way, successful attacks against the web servers [1] would still > require subsequent successful attacks against the database [2] before > getting at this sensitive data. > > > > I hope that lots of encryption is being intelligently used throughout this > application -- in transit AND at rest. > > > > *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> > *Exploiting Technology for Business Advantage...* > * * > > [1] Where we hope not to find database connection strings > for privileged accounts > > [2] Which would now be trivial > > > > *ASB *(My XeeSM Profile) <http://XeeSM.com/AndrewBaker> > *Exploiting Technology for Business Advantage...* > * * > > On Thu, Oct 7, 2010 at 1:53 PM, Klint Price <[email protected]> > wrote: > > So what steps should be taken to secure it since no instructions are > provided to do so? > > > > Because IIS knows the password for the xyzweb account. If someone can get > IIS to execute arbitrary code (e.g. by uploading some of their own webpages) > then IIS can connect to serverB using the domain\xyzweb account, and that > account has privileges on serverB. > > > > By running your website as a domain user it is basically giving permission > to your web server to access anything that the user has access to on the > entire domain. Wouldn’t that mean that > if someone manages to take advantage of one of the many IIS vulnerabilities > they very well may have access to information all over your network instead > of just the one machine? > > > > A workaround or possible solution would be to instruct the customer that if > they are going to use a domain account (which by architecture they are > forcing them to do), that they should use a non-privileged account, and > remove it from the “domain users” group. That way the account can be > considered “authenticated”, but has no other default rights on the domain. > Additional settings should be implemented to prevent the password from > expiring, and locking out. > > > > > > > > *From:* Brian Desmond [mailto:[email protected]] > *Sent:* Thursday, October 07, 2010 10:49 AM > > > *To:* NT System Admin Issues > *Subject:* RE: Need System/Application Security Advice > > > > *It’s very common. There are many things you simply cannot do if you run > in a local security context. FYI if you run the app pool as Network Service > on a domain joined machine that provides it the domain rights of the > server’s computer account.* > > * * > > *If an internet facing app even not in a corp environment runs on a web > farm and is anything other than static content you’re almost guaranteed to > have a domain and shared domain accounts running it too.* > > * * > > *Thanks,* > > *Brian Desmond* > > *[email protected]* > > * * > > *c - 312.731.3132* > > * * > > * * > > *From:* Klint Price [mailto:[email protected]] > *Sent:* Thursday, October 07, 2010 7:36 PM > *To:* NT System Admin Issues > *Subject:* RE: Need System/Application Security Advice > > > > Internal corporate, yes. Directly exposed to the internet? I would hope > not. > > > > *From:* Brian Desmond [mailto:[email protected]] > *Sent:* Thursday, October 07, 2010 10:34 AM > *To:* NT System Admin Issues > *Subject:* RE: Need System/Application Security Advice > > > > *Ermm what you describe (as I understand it) is probably how 75-90 percent > of apps run on IIS in a corporate environment.* > > * * > > *Thanks,* > > *Brian Desmond* > > *[email protected]* > > * * > > *c - 312.731.3132* > > * * > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
