Controlling Privileged Access

First, I define privileged access as anything above what the standard user would get?  How do you control privileged access?   Do you allow your Linux system administrators to have the root password?   Do you Windows administrators have the password for a system account with admin privileges?  Or maybe they have domain admin rights assigned to their personal account.

A while back I attended a presentation about for a product that stores the passwords for accounts…the assumption is that all privileged accounts would be stored in this solution along with the passwords.  This system is also capable of being integrated with AD and your ticketing system so when a user needed the password, the system would check to make sure there is a valid ticket (incident or change request) and that the requestor is also in the right AD group.  This security solution will also change the password after a set amount of time from when the password was retrieved.   This would seemingly prevent the user from reusing the password for an unlimited about of time.

While I can see why management and Internal Audit would love this solution….on the surface it meets the compliance requirements for controlling access and assists with the change management process.  This system is also very useful in storing passwords that don’t get used very often, thus making sure they are available in a business continuity situation.   However, does it help a company be secure or does it give a false sense of security?    

What are the actual actions performed when the password is retrieved?   The IT guy could retrieve the password and make any change under the guise of whatever the Incident or Change ticket talked about.   Every environment has those system accounts where the password is never changed.  These accounts tend to have a high level of privileges and everyone on the team knows the password….so no trouble ticket is required to use these accounts.   I could go on and on, but you get the point.

What is the solution?  So will argue that the administrators need admin privileges all the time….it is their job.   I don’t necessarily disagree with that.   I believe the solution lies in monitoring what the privileged accounts are doing.   Implementing one of the solutions that monitors key folders, directories, and files for access and modification is also needed.   

Until next time…

~Skeeter

Data Protection at all Levels

We all know that we need to protect the employee and customer data from unauthorized access.  We also are aware that there are many rules around the storing and transmitting healthcare and credit card data.  Most of us have went to great lengths to put security controls in place on our Production environments to protect this sensitive data in accordance with applicable policies, rules, and regulations.

What have you done to protect the data on your non-production networks?  If you have a test / QA environment that is used for functional, security, and user acceptance testing, what data is being used to ensure testing is against the “exact” data that is in Production?   Some enterprises might use an extract of the data from Production in lower landscapes for their testing.  Are all of the same security controls in place in the test / QA environment?  Or have the controls around privileged access been relaxed to make it easier for testing?   Or maybe you have password standards (probably relaxed) in the test environment? 

What about the development environment, I am guessing the security controls are even more relaxed for DEV.  The developers probably have access to just about everything and are able to manipulate the security controls to make their job easier.  Where did the data come from that they are developing against?   Was it copied straight from Prod or was it scrambled?   Or maybe if you are lucky, the developer just created their own data to use.

I understand the need to use properly formatted data…..but if you are going to use any sensitive data from the Production environment (include employee database for a HR system, sensitive company for an ERP system, customer data for customer relationship database, etc….) make sure it scrambled in some manner to make it seem that it is just random data.    Also, don’t allow the key security controls to be removed in the lower landscapes, make the developers and testers understand the need for the controls.

Until next time…..

~Skeeter