federalcto.com The Blog of a Federal CTO


The Advanced Persistent Threat and Cybersecurity Webcast

For those of you that tuned into today's webcast with myself and Paul Harper, thank you.  If you haven't seen it, it will be available shortly, and I will post the link back in this blog post.  In the mean time, if you'd like a copy of the slide deck I used today, here it is: 20110314_-_Insider_Threat_Webcast


Et tu, brute?

It’s evident throughout history – inside jobs. Aside from nuclear war and weapons of mass destruction, cyber attacks pose the single greatest threat to US security – and they are growing more and more difficult to prevent. One clear indicator of the threat is the sheer volume of breaches. Cyber attacks on federal computer systems have increased more than 250% over the last two years, according to the Homeland Security Department. Federal computing resources are under constant threats -- not only from the outside, but also from trusted partners and internal users. Cyber attacks are a clear and present danger and the potential for both accidental and deliberate breaches of sensitive information is a growing concern. Innocent but careless employee actions can set the table for attacks by more malicious parties. In many cases, the threats are inadvertent, with users unwittingly introducing harmful viruses to your agency or allowing sensitive data to be leaked.  But whether or not there’s malice, the damage from breaches can be great.

Join me for a discussion on Monday, March 14 @ 1:30 pm ET on ways to protect your environment from the inside threat.  We’ll talk about how you can not only improve your security posture, but also meet regulatory and statutory guidelines during audits and reviews.  Plus, you’ll also learn about forensics and tools you’ll need when a breach does occur to minimize the losses and downtime.

You can register here. I’m looking forward to hearty discussion.


Token Bloat, AD Bridge and Quest Privilege Manager

If you don't know what "token bloat" is, then I suggest you do some research.  Plenty has been written on it, and while I'll provide a brief description, others do a much better job of covering it.  The short version is that when you log in using your Active Directory credentials you get a Kerberos ticket (which is just your identity - who you are) plus a PAC (Privileged Attribute Certificate - which is a list of all your security group memberships (their UUIDs, actually) - what rights you have).  As a user gets more and more rights (through group membership), the PAC grows.  Eventually, it becomes big enough to affect logins and applications that use the AD Kerberos ticket (often called a token).  The effect is that things slow down, or just flat out break.

But how does this affect AD Bridge products, like Quest Authentication Services?  Unfortunately, in much the same way.  If you're a member of 10,000 security groups, it's going to take some amount of time to get through that list.  That doesn't change just because you've logged into a Unix, Linux or Mac machine.  At best, you can set a flag to ignore the PAC if all you want is authentication, but if you are a member of 10,000 groups, someone probably put you in those groups for a reason (note: 10,000 is hyperbole, and if you really are a member of 10,000 groups, you have some serious AD design problems).

And an increase in the number of groups is often a by-product of deploying an AD bridge solution.  We have other ways to alias out and re-use existing groups, and you can certainly use local groups, which are not in the PAC, but who wants that?  In some cases, you want those added groups.  You need those added groups.  A unix sysadmin is not the same as a Windows administrator.  And an Oracle DBA often has different rights, and requires different groups from your SQL Server admins, so simply generalizing your groups aren't enough, either.

But for customers that have QAS along with Quest Privilege Manager for Unix, there's a better way.  And one that provides a lot more flexibility and configuration options. Plus, you don't have to have QAS.  You can do this with local accounts, LDAP, NIS, and any other users you have on unix. I'll just stick with AD users because the topic of this post does focus on 'token bloat' which is an AD-specific problem.

What is Quest Privilege Manager (QPM4U)?  It is a tool for unix command control, and I/O logging.  There are lots of other descriptions people use - "Tivo for your unix machines," or "sudo on steroids" are often used, though most fall short in a 1 sentence pitch.  QPM4U allows very granular control over what rights users have on a particular machine, and that granularity includes options such as time of day, and day of week, environment variables, and multiple group memberships. In fact, it can use any variable/attribute about the user, the machine and environment.

And the last item I listed (multiple group memberships) is where things get interesting.  You actually write a rule that says, "if a user is a member of OhioUsers, and a member of SalesTeam, then the user can access files in the /SalesDocs/Ohio folder."  This is interesting, because in the Windows world, most people would be added to the SalesTeam group, and the OhioUsers group, and then a third group would get created called 'OhioSalesTeam' just to grant access to a similar folder.  And even with sudo, the same thing would happen.  Sudo can only check for 1 group membership, and you're either in the group, or not.

This is where QPM4U can let you use existing groups, and perhaps other attributes, to determine whether users can access resources or run certain commands.  In fact, you could simply query AD (check out the 'vastool search' command), find out the user's job title (Account Manager), their state (Ohio) and make the determination that way.  Which means that no groups are needed.  This is an extreme example, and not one I'd recommend, but hopefully you see how it could help prevent token bloat.  In addition, you can start adding in other conditions, such as time of day (if the user is a DBA, and it's after 7 PM, then they can run the 'backup database' command), allowing for even more flexibility, and control.

Now, I've been writing all this using pseudo code, and not showing you how simple this config would actually be to put in place.  So what would be needed in the Privilege Manager config file for that initial scenario? Well, thanks to my colleague, Paul Harper, it would look something like:

# check all the arguements to see if the filepath is the one allowed
c = 0;
protected_dir = '/SalesDocs/Ohio/';
prot_dir_len = strlen(protected_dir);

while (c < argc) { 
   if ( (strlen(argv[c]) >= prot_dir_len ) && ( strsub(argv[c], 0, prot_dir_len) == protected_dir )) {
      if (ingroup(user, "SalesTeam")) && (ingroup(user, “OhioUsers”)) {
      else {
  c = c + 1;
  # do other things here for other conditions.

To be fair, this is a poorly written script, and it has many faults, but it gives you an idea of the types of things that could be done with Privilege Manager, especially when it comes to multiple groups, and the fact that you can check for multiple group memberships, without having to create a brand new group just to manage access to a resource where other conditions already exist to check this.

There you go, Jeff. Hopefully this post helps you - give me a call if you've read this far down.  🙂


The Federal CIO’s guide to partnering with Quest Software for Data Center Consolidation, Part I

[Note 1: the bulk of this blog post was done on an Apple iPad - I point this out not because of a fascination with the iPad, but because of the fact that such long documents were not readily possible from a mobile platform only a few years ago.  That still amazes me.]

[Note 2: this is a very rough, stream of consciousness blog entry.  Grammar, spelling and other writing errors should be ignored. If you want a nice, clean "white paper" type of document, please contact me offline, and I'll get you something cold and clinical.]

The current administration has developed the Federal Data Center Consolidation Initiative (FDCCI) with every agency and department falling under scrutiny. It is  mandated by administration as a way to cut costs as well as secure the environment. This document does not seek to go into detail about the FDCCI but outline how Quest software can help every agency and department with the overall initiative.

The focus of the initiative is on physically collapsing all centers to a much fewer number. Of course, this is not just an exercise in put all the servers into a single room.  This is an opportunity to both consolidate, and update the environment as well as potentially modernize key systems and platforms.  And this is where Quest can help.

At a high level, the entire consolidation will involve the following steps:

  1. An assessment of the current environment, determining the disposition of every item to be included or excluded from the consolidation
  2. As part of the assessment, it is good to determine and establish baselines for services
  3. Prep work to get platforms or systems ready to be moved to their new environment - this includes any procurement and training that needs to occur
  4. The actual movement itself, which may be as simple as putting the same server into a new location or as complicated as migrating to an entirely new system on new hardware, operating system, platform, etc
  5. Tuning and optimization of the systems to their new environment
  6. Post-mortem review and on-going monitoring and maintenance

Depending on the agency or department, the age and condition of the systems, the number of users and administrators involved and the number of data centers, the time for each step will vary.

In all of this, personnel will also be affected. Not only may IT staff have a new location to go to, but they will also need new skills and tools. And with this, it would be good practice to audit and adjust access controls to make sure additional rights are not unduly granted.

Over the next few weeks, as time permits, I will be exploring the different areas of this sort of project, and tying it back to solutions that Quest Software provides. The hope is to give a good, solid overview of the help available from Quest in making this move.  Many of the topics covered will also apply to other situations, and later on, I'll make the case that many of our solutions are "dual purpose" meaning they may be used by one set of users for a particular task, but that a different set of users may also benefit from the same tools in a different capacity.

First off, it would be helpful to review what Quest's goals are in providing the software that they write. At a high level, Quest is a systems management company.  We do not have many of the platforms that people traditionally think of when they think of an enterprise software company; databases, web servers, operating systems, etc. For example, no one needs another database platform, at least not from us.  But organizations do need to get a better handle on their existing databases, database servers, and the systems that use them. And that's where we come in.

We focus on making your existing infrastructure easier to use. This is not to say all our tools are simple. Yes, we have "Simplicity At Work" as our tagline, but we do some pretty complicated things. And while the overall message does make sense to someone familiar with the problems we solve, these are not "Fisher Price" tools. The common misconception is because we have some products that have the word 'wizard,' that they are easy. No, what it means we make whatever the wizard works against easier to use.

Lastly, it would probably be good to give you an idea of who I am and what I do. I am currently the CTO for Quest's Federal Public Sector group. Which means I keep an eye on all things Federal, working with clients and partners to help them get the most out of Quest while also working internally to make sure our solutions align with my customers' needs. We have many other people with similar roles, however I don't have a single area of focus.  We have over 150 products, and anywhere from 3-8 different areas (depending on who you talk to). So I try and stay current with everything we have to offer.

And though I've worked with Public Sector clients since I arrived at Quest over 5 years ago, I've also worked for Quest in the UK as well as on the commercial side in North America. In those instances, my remit was Identity and Access Management as well as our overall Windows Management solutions. Before all that, and joining Quest, I was a developer, DBA, Director of IT, University instructor and a whole host of other things.

That's enough for now, and should give you a good enough idea of where this blog is headed over the next few weeks. If you have any questions or comments, don't hesitate to write me (dimikagi -at- federalcto.com) or post them up below.


Upcoming posts

I have several posts queued up that are quite detailed about how Quest can fit a data center consolidation strategy.  But in the meantime, I have this post on a related site until those are published:


As the title suggests, I talk about how to block USB mass storage and CD-ROM drive on a desktop, and complementing it with a Quest product called ActiveRoles Server to add and remove the machine from groups on a temporary or ad hoc basis.

Copyright (C) 2010-2011 Dmitry Kagansky – All opinions expressed are those of the respective author and do not reflect the views of any affiliate, partner, employer or associate.