Data Protection

So you’ve done all you can to secure your systems. You use and enforce different, random, complex passwords on all services.
How do you know that they are protecting you?

Bad News:
Well, no service is ever going to be invulnerable to attack or abuse.
Remember, the worst case scenario is that an internal employee abuses their position of power/responsibility and your information is then exposed.
This list of individuals can be controlled, but not eliminated.

• Company Processes
  • HR
  • Executive/Management
  • Customer Support
  • Legal
• IT Processes
  • Operations
  • Programmers
  • Analysts
  • Security
  • Support
• External Processes
  • Legal
  • Backups
  • Disaster Recovery
  • Support
  • Service Providers

Fun, eh?
Can you guess which of these groups you simply cannot prevent accessing client data?
It is a surprisingly long list, but access isn’t necessarily automatic for all people listed here. Some inherit access from older processes before proper Data Protection and process controls are in place.
Processes:
Most data access issues arise from inappropriate access. This arises when the applications and business processes in the background within a company are not fully formed or simply not applied.
Here we see more problems with easy fixes than most others.
Exposure of client details to corporate management, human resources etc. is not usually required. They need to see the overviews and reports, not the entire system. There will inevitably be occasions when management will see client details, but these will be provided upwards by other processes/persons. Seems harsh, doesn’t it, to tell management they must ask for access to the system? Try being the person telling them that. Then avoid the BOFH monicker.
It’s an awful lot easier now. The law and public pressure demand a different response to the old school “Do you know who I am?” management scheme.
Beginning…
Ok, we want to get it correct from day one, don’t we?
Then here are the primary rules I feel we need:

• Logging
• Identification
• Access Control
• Process Control
• Authorisation/Sign off
• Risk Assessment
• Handover

Only Seven? Well, yes. They are, in fact, categories for policies rather than rules in and of themselves. Each provides a different level of protection. Each adds to the value of the service too, allowing audits and verifications to be performed with sincerity and openness.
Security Up:
First underpin your IT projects with the principles of Security First. Each design element should be critiqued for security before moving through to any development, test, preproduction or production environment.
Do that and the rest will follow.
Logging:
Each and every system has the ability to log every action. Honestly, they do. We do, however, need to ensure that ACCESS is logged and recorded for our purposes. Actions/controls etc. can also be recorded.
The problem is storing and securing such logs. The number, types and affects of transactions can easily be factors larger than the original data you are trying to protect. The trick is finding the level of logging that allows you to state that the system is “appropriately” audited. This is a long and difficult discussion.
I always recommend a remote, preferably encrypted logging storage model. The logs give away a huge amount about how your system works. Protect them! Also ensure that you archive them if possible rather than destroying them.
I have been asked by governmental and legal representatives for raw logs dating back to 15 years. Now they may have been “data fishing” hoping to find a problem, but find out what the level of requirements are and ensure you adhere to them. It may be a requirement that logs are destroyed within a legally defined time limit.
Keep the logs pertinent too. You must not store data from the original transaction if it can be avoided, for example, a user’s credit card number or address. If it is essential to record these transactional items then ensure they are encrypted before logging, above and in excess of the logging encryption itself.
Identification:
Essential. Each and every administration/back end process must be appropriately secured to individuals. I repeat, each user should have a unique login. Additionally, after testing access levels, enforce a change of password for the user on first connection (and regularly thereafter). Now, only they can login as that userID.
Try your level best to disable or restrict global, generic, group or shared logins. There is no audit trail there.
If you do need the superuser/administrator account then be extremely vigorous with the login. Perhaps even notify your security department automatically when the account is accessed.
Access Control:
You need to design the application and system such that you can deal out access at a variety of levels. These need to be both functional and departmental restrictions.
The principle is to ask the user:

• What do you need to access?
• What do you need to see?
• What do you to do?

Limit the commands/processes available to only those required by the user to perform their job.
Limit the scope that is covered to that required by the user to perform their job.
Potentially, you should be able to engineer a UI to allow all this as part of the concept/design of the service. This is Security Up systems architecture.
This goes for all levels too.
If HR need to see who accessed employee records, write a GUI.
If an engineer only needs to read the mail logs, write a command line tool or restrict his login.
Process Control:
Here you need a proper handle on good HR etc. practices. As people join and leave the organisation, logins also should be created and destroyed. Ensure that destruction of a login does not make your logs useless.
Ensure that disused accounts are suspended.
Ensure that suspended accounts are deleted.
I am sure that there are many things in this section people can apply models to, but it is part of the business culture and may need a serious overhaul. See details above.
Authorisation/Sign Off:
Easy one, but easily ignored.
Part of Process Control really, but important enough to have it’s own segment.
Ensure that an appropriate person understands and authorises the level of access granted. This may not be the department manager, but might be. The Security Manager certainly won’t thank you if they have to authorise every access request.
If the the starters process is correct this will be automatic (self evident) anyway, but certain higher access levels should always go through an approval process.
Obviously, having all this in place means you have applied the appropriate levels to all employees. If someone wants information above their normal access then it goes through an approvals and sign off process, usually through senior management and security management if the exposure is large.
Risk Assessment:
Nearly finished now.
The next important step is to ensure that you are aware of the exposure that is provided at each level. This should be properly documented and, once again, signed off. This time, the sign off must include the project sponsor or senior management before the system is live.
Awareness of the Risk Assessment could be important if the data is customer related or extremely sensitive.
The Risk Assessment should be reviewed regularly. These reviews should include, if possible, a run down of who has particular access rights and hopefully who authorised it and why. Just a simple table of facts is all that is required.
Ensure it is signed off by the security manager and any anomalies investigated.
Handover:
Ok and now the final piece of the jigsaw.
Ensure that at every handover (development, testing, production and any other) the access rights are reviewed and, once again, signed off.
There will be people that no longer require access or at least the same level of access after their primary task has been completed. This includes developers, test managers, UAT accessors and so forth.
Even the security manager does not need access most of the time.
Conclusion:
So, what is the answer to our little question?
Who does need full access all the time?
Simply put this would, in most cases, be no one. That is only the case, however, if the system is expected to run without fault. Has anyone ever worked on such a system?
So now we know.
Yes we do!
The Senior Operations team will require immediate, unimpeded access to the system to diagnose and fix low level underlying issues. If you make this too difficult for them you risk a significant amount of delay or damage whilst access is appropriated.
The Risk Assessment will acknowledge that this Operations team is where your primary trust is laid. This is often called “Keys to the Kindom“. They are the team that will grant the lowest appropriate level of access to others. They can even assign a “hidden” series of logins to themselves and appropriate your data from there.
Of course, you’ve still got your secured, remote, encrypted logging. Think to yourself though – “who’s maintaining that server/service?”
You cannot avoid giving the operations team the ultimate access that so many employees, malcontents, hackers – possibly all of us – crave.
References:
The Tech Herald – FBI arrest AT&T Insider
Times of India – Cyber Police Arrest
Social Engineer – Morgan Stanley Disgruntled Employee
Risk.Net – CME Employee Charged
Finextra – BofA Worker Arrested
The Register – Ex-Employee Jailed

– Posted using BlogPress