Showing posts with label security. Show all posts
Showing posts with label security. Show all posts

Sunday, February 7, 2010

Harden Your Service Accounts

In many cases we have service accounts that need powerful privileges to perform their tasks. This power also means that there is an elevated level of risk associanted with these accounts. They could be used inappropriately to access resources without accountability, since they are not tied directly to a person. There are two steps that I recommend that people follow in locking fown these accounts. Both of these activities involve starting Active Directory Users and Groups and then selecting the Properties options on the selected service acccout. First, select the Terminal Services Profile and check the option to Deny this user permissions to log on to any Terminal Server. The screen shot is listed here:

Then we want to restrict the computers that the service account cal log into. This is found on the Account tab. Once on this tab, click on the Log On To command button. At this point enter the computer name(s) where the service account is used. This will limit the account to logging into only this machine.



Friday, January 8, 2010

8 Predictions for 2010 on Document Management Security

Each year there seem to be more and more breaches in information security. Some only cause embarrassment; others could cause harm. Take a look at this list of my predictions that I prepared for AIIM. Could you be affected by any of these items? If so, start locking down your information effectively. I would love to hear your feedback.

Tuesday, December 1, 2009

Who Stole Those Emails

I have started writing a column for Infonomics, the publishing portion of AIIM. The first column covers the basics of Information Security. Here is a link to The Article.

Saturday, June 6, 2009

Active Directory Security Groups

Yesterday, during a Varonis training session, Paul Ezhaya started a great discussion by asking my opinion on strategies for naming security groups and organizing folders on file servers. The primary debate was whether to use security groups named after departments and roles or to use security groups named after folders that they provide access to. For example, if there was folder called Human Resources with sub-folders such as Employee Data, Forms, and Terminations, and folders specific to several departments how would we set this up from a security perspective? Would we create Active Directory groups based on Roles for the HR people who handle each department and then apply those groups to the corresponding folders on the file server? Or would we create AD groups named after the specific sub-folders and then add the specific people to those groups as needed? Along with the security groups we would take the lead in organizing the folder structure to match the security group naming conventions.

There is no “right” answer, but here are some of my thoughts on the Role versus Folder question.

In general, I prefer the Folder-based solution. The first reason is for the long-term security of your organization. Finding the data is always top priority so regardless of how you organize the folders; users will learn the taxonomy and adjust to it. You need to force the organization to apply security; therefore, if you organize the infrastructure in a secure manner, they won’t have to. Second, When you first set up your Role-based Security Groups you might have an accurate grouping of the users by department. However, over time people will not make the appropriate adjustments to those groups. After the initial setup fades away, when you add someone to a role-based security group to they can access a particular set of data, you may not realize what else that gives them access to. You may not it even give it any consideration because security will always be an afterthought. In a Folder-based solution, the security of the data is pushed to the forefront as the IT department knows what folders the Active Directory group gives them access to. And if the access is insufficient user will surely let you know, where the odds of them notifying you that they were given too much access in the Role-based scenario is highly unlikely.

Of course, we may have a hybrid approach. At the top level shares we might want to have security groups for the department and apply those at that level. Then we would turn off inheritance on folders with confidential data and apply the folder-based security to those folders. So we end up with a set of groups like this:

grp_HumanResources
grp_Terminations-RO
grp_Terminations-RW


Where RO is for the group with Read Only privileges and RW is the group with Modify privileges.

If there are other reasons for you to use a Role-based strategy then I would highly recommend an automated Identify Access Management system. I think that you will still find that the default will be to provide too much access, but the results will be better.

Tuesday, May 19, 2009

Adobe Acrobat Requires Critical Security Update

It is astonishing that software that was created to present documents in a "neutral format", Adobe Acrobat, can be hacked. Another case of taking a great product and adding features that eventually take the software far beyond the original architecture and creating security vulnerabilities.

Why is JavaScript even an option in PDF files? PDF files were suppossed to be the safe alternative to documents that you might receive in formats such as Word. I guess that has gone by the wayside.

Here is the link to Adobe's update site.

US-CERT has more detail about the vulnerabilities and other workarounds and protection methods on their web site.

Monday, May 4, 2009

TechRepublic Reviews Varonis Suite

The TechRepublic blogger Mark Kaelin has a review of the Varonis Data Governance suite.

Here is a link to the review.

Nice to see the product get some coverage, since it is the greatest thing since sliced bread (actually since VMware). The review mentioned three things that are wrong with the product, I take issue with two of them.

Issue 1 that I disagree with:

"Culture shock: The general principle of placing decision making concerning data governance in the hands of employees deep in the organization may be a significant change of policy for many established organizations, especially those with established hierarchical structures and controlling IT departments. "

One of the advantages of the Varonis solution is that you can start small, with one directory if you want, so that there is no need for any culture shock. Security provisioning by the user community can be rolled out as slowly or as quickly as the organization can handle.

Issue 2 that I disagree with:

"Cost and scope: The scope of the Varonis Data Governance Suite 4.0 does not come cheap. Not only will the entire organization have to buy-in to the concept, the initial software installation and training cost will be significant. This suite of software is most likely to be used in larger organizations with very specific and vital data governance needs. "

The cost of the solution relative to the value of the data is not significant and in terms of improved efficiency of IT administration the product more than justifies the cost. We have a number of customers that are small (250 users) and see significant benefit from the DatAdvantage product. Again the "enterprise" buy in is not a necessity for implementing the solution. Behind the scenes the DatAdvantage solution monitors and reports and access without disturbing anyone and the Data Privilege component can be rolled out directory by directory if you so desire.

Tuesday, April 28, 2009

Are Your Admins Accountable?

A comprehensive security process protecting critical assets needs to follow a basic outline such as this:
  • Prevention
  • Detection
  • Reaction
  • Correction

Access to servers is one area where I see this process break down all the time. First, people reasonably Prevent access with passwords. However, they use a common account such as Administrator; which seriously weakens the Detection and Reaction steps. If every system administrator is using the same privileged account to do their work, there is no accountability (a key component of detection) and no reasonable ability to React when something goes wrong.

CIOs, don't let your admins grow up to be cowboys! Make it a policy and practice to require that system administrators use their own accounts to perform their jobs.

Thursday, April 2, 2009

Two-factor authentication comes to Main Street

Security can be a wonderful thing and if it is well thought out and it does not have to be onerous.

I have seen an increase in the number of merchants who are asking me for my billing zip code when using my American Express card. Walmart has been doing it for years. Many gas stations have started and last night, Walgreens asked me for the first time.

This is a great example of intelligent two-factor authentication. The transaction relies on “something I have,” the credit card, and “something I know,” the billing zip code. Something that is easy for me to remember.

This is much more effective than a signature because the credit card processor can easily validate my zip code as compared with analyzing handwriting. If security involves a cycle of:

  • Prevention
  • Detection
  • Reaction

the use of the Zip Code raises the ability of the bank and merchant to prevent and detect a fraudulent transaction.

Several years ago someone stole my credit card and spent about $300 before I noticed the next morning that the card was gone. Had the thief been asked my zip code, he never would have been able to order that $50 meal at McDonald’s. Let’s hope that more merchants follow this protocol and we see a drop in credit card theft, saving all of us money in the long run.