News Feed

Security News Feeds

Tuesday, July 29, 2008

The CodeWeavers Lame Duck Presidential Challenge!

The CodeWeavers Lame Duck Presidential Challengewill make its software products downloadable for free to all Americans for 24 hours at if President Bush accomplishes at least one of the following goals:

read more | digg story

Saturday, January 19, 2008

Curiosity of Local vs. Domain level Security

My first post for the new year is one that I think all Information Security professionals have to deal with at some point within their careers, it is the age old question of local security vs. domain level security (GPO in particular). Through the research I have conducted, there are multiple takes on this subject, but no one clear answer as to which is best. Bottom line is that the answer is unique to each environment, and you should weigh the business case for each solution on it's own.

Since this is my blog, I'll impart on you my own personal thoughts on the situation. To me, putting faith in either solution has risk. With local security, there is the chance that someone with administrative rights can come in and make changes. In turn, with Domain level security, there is always the likelihood of the systems not getting the security applied due to technical issues. For me this leaves only one logical option. A hybrid of the two mechanisms is most likely the best answer to ensure not only that the proper security is applied, but that that security policy is enforced at a given time. To achieve this, my best option would be an 80-20, or 90-10 type of rule with the majority of the security applied locally as the assets are provisioned. In turn, any asset attached to a domain, could have the remaining security setting applied by the group policy, and the entire policy can be enforced on a regular schedule. For systems not on a domain, 100% of the settings would have to be applied locally, and a "Control" mechanism would have to be deployed to ensure that the configuration remained consistent with the intended policy. There are a couple of sure fire ways this unique challenge can be overcome. First would be to use a product such as Tennable's Security Center 3 that would allow you to run "Audit" policies against your configurations. This would report and discrepancies against the applied policy vs. the audit policy. You could then manually deploy the corrective actions over an automated system, or schedule them as manual corrections (not always the best option). Another way to ensure that policy is adhered to at all times, would be to use an automated compliance and remediation product such as Symantic's Altiris Security Expressions, McAfee's Policy and Remediation Managers, or BladeLogic's flagship product. These types of systems run audits and have the ability to auto-remediate any potential discrepancies. Finally, there is a fail safe that would work with either of the options, and this is to ensure that you have a log monitoring solution that can report on changes, failures in policy application, or any potential changes made by users. These reports come in very handy as a compliance mechanism, as the logs associated with most security settings are very verbose, and can be setup to monitor most all of the activities that occur on assets.

To close, the best option will always depend on the environment in which you are assessing the security, and a flexible, multidimensional aspect of solving the problem is often the best way to ensure overall compliance remains in sync with the intentions of any security policy that needs to be enforced.