I am tired of hearing about companies losing customer data and how its becoming a commonplace expectation that a customer should expect this to happen. In this day and age with all of the technology available it seems we can’t get the simple principles of security right. Pick any of the breaches that have happened in the past couple of years, and had those corporations followed good security practices those breaches would never have happened. These are not leading-edge technologies I am talking about; they are basic foundations of security that just happen to be delivered through technology. I find my customers that are most successfully protecting their consumers’ data are establishing fundamental pillars of security foundations and then picking the technology. Going back to these basics will help you close the gaps.
First is separation of duties. What this means is someone who can grant rights to access a system should not have any rights themselves on that system, and someone who has rights on a system cannot grant access to that system. A simple example would be to think of your systems that run your company’s finances. The person in IT that grants access to the systems for the employees in finance should not have any access to those finance systems themselves. The finance employees accessing their systems cannot give access to those systems to anyone else. This way you do not run the risk of anyone in IT being able to access payroll, salary, etc., information on your finance systems. Their ability is simply to grant or deny access, but their own account cannot be used to access the systems.
Second is least access privilege. This means when you get access to a system you have the privileges to do only what you need to do in order to accomplish your job. Think deny all privileges first and then grant specific privileges as needed to perform a job. This means taking users out of the administrator or wheel group, basically any group granting administrator or root equivalent privileges. You can’t have two accounts in windows, one regular one and one account for administration. That is not solving the problem, it is just a poor attempt to try and make it easier to identify who did what from your log files. You are still giving away the keys to the kingdom.
The fact that they are doing things under a known “-a” account does not remove the privileges they have. You can’t use a password vault to check out a high privileged account because after all it’s still a high privilege account. You have opened the window for the user to do whatever they want. The problem with both the vault and the “-a” account is that you are using an account that has the ability to do anything on a system, and someone has the keys to your kingdom. With this access it would not take long to do damage. Sure you have a record of what they did, but the breach has happened, your credit card number is gone, they have created other accounts with privilege to continue accessing things, they have planted a Trojan horse, etc. Game over. Whether you are on a Unix, Linux or Windows system, you should only have the specific rights required to do your job, which is what least access privilege is all about. Most of the higher security conscious organizations will have some form of user activity auditing. The added benefit to restricting accounts permissions is that whatever you use for auditing now is recording what a named user is doing on the system, and not some generic or shared account requiring you to track down which person used it. Your auditing solution is very valuable to let you know exactly who in the organization made a change. Think of the pass-the-hash and pass-the-ticket attacks since a bot or malware goes around the network using user account password hashes to get from one system to the next looking for an admin account password hash. Once they find one, game over they have your network, you’ve been owned (http://en.wikipedia.org/wiki/Pwn). So, we recommend that you eliminate using any of the full admin rights models in favor of a least access model. Mitigating this issue with least access privilege was covered by Centrify CEO Tom Kemp in one of his blogs at http://blog.centrify.com/pass-the-hash-attacks-windows/
The third item is trusted computing as represented in this high-level diagram above.
When I say trusted computing I am talking about having a rule set that defines which systems are allowed to communicate to other systems. The most popular way to do this is to use IPSec Transport Mode (a good comparison of IPSec Tunnel and Transport Mode can be found at http://www.firewall.cx/networking-topics/protocols/870-ipsec-modes.html). With this method you define a policy for your PCI set of servers so only employees’ workstations that have a “need to know” can access those systems. With IPSec every packet of data sent between those systems gets validated by a strong identity of the server as registered with Active Directory using either PKI Certificates or Kerberos Tickets. IPSec is a lot like S/MIME for TCP/IP packets since it is capable of signing and encrypting the messages/packets so that only the correct person or computer can communicate.
You can also optionally encrypt the data in transit with minimum overhead. All of this enables you to eliminate a man in the middle attack. If someone gets a system onto your network (which if firewalls were really doing their job, then there would be no data breaches, right? Just read the Verizon data breach report http://www.verizonenterprise.com/DBIR/2014/reports/rp_dbir-2014-executive-summary_en_xg.pdf) and knows user credentials (remember, the pass-the-hash attack enables them to use an admin account that gives them full access everywhere, especially for a Domain Admin user) that give them access, it does not matter. The reason is their system is not a trusted system so any computer they try to communicate with simply ignores them. Implementing IPSec in a retail environment eliminates the risk of a hacker getting onto a store’s network and being able to do things such as access your point of sale (POS) system to install malware in the first place. Windows has provided IPSec support in their products for many years for free (see http://technet.microsoft.com/en-us/network/bb531150.aspx for details). Centrify delivers this support for Linux and UNIX systems so you can extend what you are already doing in Windows to those systems. You also get the added benefit of automatic PKI certificate distribution/renewal. You can get a good idea how this works from the diagram below and find out more about this at http://www.centrify.com/platinum-edition/server-and-domain-isolation.asp.
If you implement these three foundations you have not only made your enterprise more secure, you are going to significantly reduce the amount of time you prepare and go through audits. Instead of spending weeks finding out who has access to what systems, you can provide that information at a click of a button. You can show the auditors exactly what permissions users have on your systems as displayed in this report.
Finally you can lock up the use of any high privilege accounts, such as Administrator or root accounts, because no one has a business need to use these accounts. Since you have your users locked down to use only the permissions they need for their jobs, you have trusted communications on your high value systems so that even if an account gets compromised, it doesn’t matter because the system they use to get on your network is not trusted to communicate with your other systems.