Thursday, March 20, 2014

Effort vs. Recognition

Today I'm writing only the second ever non-technical piece on my blog.  The first can be found here, and touches mainly on ethics in dealing with customers and putting the customer first, always.  Today's post is a bit more introspective, focusing on why we do what we do, and the rewards, if any.

Me, I am a techie, I want to know and understand how things work and then I want to put that know-how to use so that my customers can obtain the maximum benefit out of their investment.  My boss also comes from a technical background, which is brilliant because he “gets” it, even though he has long since left the technical side of things behind.  In fact one might say he went over to the dark side, since he is much more involved in sales nowadays.

That said, a lot of what I do is impossible for my superiors to grasp nor does it immediately reflect on a financial balance sheet.  A big part of that is also undoubtedly the fact that oftentimes I simply do not know how to elucidate or explain it in terms that anyone than a peer would understand.  I do know however, that what I do will save someone a lot of trouble and effort down the road.  It might not be today or tomorrow, but it *will* prove to valuable.

Every manager will tell you that something that can't be quantified can't be measured, and what can't be measured can not be recognized.  It follows that what cannot be recognized can not be rewarded.  This brings us to an important question - do we do something the right, proper and ethical way because it is right, or because we want to be rewarded?  

I feel that we are defined by our actions, thus we become what we do.  So put in the effort.  Chances are you won't get credit or recognition for it, but that is OK.  Even if no-one sees it, *you* know.  You do it because that is who you are.  And if it's not who you are now, it is who you want to become.

I really believe that integrity and the excellence that goes with it will get rewarded in the long run.  You might find yourself thinking "what did I do to deserve this opportunity", or how a seemingly random encounter turns into an amazing and rewarding professional journey.  But it's not just random luck – this is the reward.

I've been very fortunate in that I have been able to choose my bosses and managers very carefully and I can honestly say that my interaction with each and every one of them has left me a better person, both professionally and personally.  That said, bosses come and go, but you remain.  So do the right thing, not for their recognition (though it is certainly welcome!), but for yourself.

The biggest reward of all is being able to hold your head up high, and be proud of what you have created.  Be proud of who you are and what you do.

Wednesday, March 5, 2014

Disabling the Symantec DLP Agent notifications

I’ve been branching out from the normal infrastructure stuff I’ve been doing into more security oriented fields.  Part of what I now do includes Data Loss Prevention, and I’m proud to say that I’ve recently completed my first Symantec DLP deployment.  It also happened to be the first deployment in Africa, outside of South Africa.

By default the Symantec DLP endpoint agent displays a notification when it scans for sensitive content, like so:
image

In this case the customer did not want to let the end-user see what was going on so we had to disable.  Unfortunately this seemingly simple UI option is not so simple – here is what you have to do

Log into the DLP Console.  Go to System -> Agent Configuration
image

-> Edit config -> Advanced Agent Settings
image

Set the UI.NO_SCAN.int to any value other than 0 and the scan dialog will not be displayed.
image

All Fortigate FSSO users are placed in the FSSO_guest_users group

Getting AD authentication going on a Fortigate is a slightly finicky, but well documented process and once you get it working it works well.  If it’s something you battle with, leave a comment and I’ll do a HowTo.

That said I recently had an issue with a Fortigate unit that absolutely insisted on putting all FSSO users in the FSSO_guest_users group, which means none of my Policies using authentication was working.  This is what the Fortigate saw my logged on users as:

image

The fix in the end was fairly simple, turns out that on the Fortigate I had the groups configured in Advanced mode, like so: CN=Internet Access,OU=Security Groups,OU=Head Office,DC=corp,DC=root. 

The Collector Agent, however, was configured to use Standard mode.  The fix was to switch the FSSO Collector Agent Directory Access Mode to Advanced Mode.
image

Once the change was made I refreshed the FSSO groups on the Fortigate via the “execute fsso refresh” command and all was well again.

For those of you keeping notes, the Fortigate was running FortiOS v5 Patch 6 and the FSSO agent was v4.0 MR3 B0151