Identity, Credential And Access Management (ICAM) In The Cloud - CecoViral

Ads Top

Identity, Credential And Access Management (ICAM) In The Cloud

Protecting data in the cloud has its own unique challenges, especially if additional compliance regulations need to be met. Here's how you can utilize two popular ICAM approaches to keep your data in the cloud safe.

In 409 A.D. Honorius, ruler of Rome and the Western Empire, refused to negotiate with his brother Alaric, king of the Visigoths, when the Visigoths marched on Rome. Honorius mistakenly believed that the city's perimeter defenses were sufficient to hold off any attack. Alaric knew better and led the Visigoths in a siege, eventual occupation and sacking of Rome a year later. Honorius' lack of vision -- and his belief that perimeter defenses were sufficient -- cost him the city of Rome. For today's business executives, putting faith in perimeter defenses can only lead to the fall of something much more closer to home -- their business and confidential data.

History teaches us that nothing lasts forever, but underestimating your opponent or overestimating your defenses can be a fatal error. Today, that means building in layered security, especially identity, credential and access management (ICAM) controls around your data, regardless of where that data resides. It seems obvious that companies will build in such controls around their most valuable data within their data center, but how does one protect private data when it resides on someone else's data center in the cloud?

Protecting cloud-based data becomes even more complicated when industry or governmental regulations require that the data be protected to meet compliance regulations, such as Payment Card Industry Data Security Standards (PCI DSS) for credit card or personally identifiable information, and the Health Insurance Portability and Accountability Act (HIPAA), or Health Information Technology for Economic and Clinical Health Act (HiTECH), for data in the healthcare industry.

There are several approaches to cloud-based ICAM popular today. One that gets a considerable amount of attention is multifactor authentication. This is useful in taking the traditional login and password to the next level, requiring the users to further identify themselves using the company's Active Directory or LDAP (lightweight directory access protocol) database as a deeper level of authentication. Another is monitoring administrative and service accounts to ensure that superuser accounts are safe.

Multifactor Authentication
Multifactor authentication refers to something you know (a login and password), something you have (a token) or something you are (biometric data, such as a fingerprint, retinal scan or heartbeat). This approach excels at requiring the user to have something physical for the server to authenticate so the system absolutely knows who you are, but it falls short of ensuring that you are authorized to access the particular data you are trying to access.

For that, authentication systems need to ensure that the user is authorized to access this type of data based on their job title or department, has the appropriate expertise or credentials to understand and act upon the data, and has either the appropriate job title, service level or other company-specified clearance level to view the data. This is the credential competent of ICAM.

Smartphones are becoming the go-to technology for tokens as traditional token technology becomes more expensive to manage, protect and maintain. Instead, many companies opt for using the employees' personal or company-assigned smartphones to serve as the reception hardware for randomly generated tokens or passcodes.

Sometimes IT managers are not aware when a department-level manager decides to employ a cloud-based application. The challenge the IT manager has is to ensure that restricted data from the corporate network does not migrate to the cloud, where it could be at risk to move outside of the company's own security controls, particularly when the data is protected by compliance regulations.

One approach to ensuring the compliance walls are secured is for the IT team to create maps of what each application does and how it impacts other applications. Once the maps are created, rules can be written so that if someone with a given set of rights tries to take an action that violates the rules, the action will be disallowed and the conflict reported. Sometimes users are granted rights based on their jobs that conflict with governmental or industry compliance regulations. A rules-based system that identifies potential compliance breaches can bring to light previously unrecognized compliance risks. These rules, for example, can prohibit certain data from moving to the cloud, even if the user trying to transmit the data is authorized for view or access from the corporate network.

While experts generally agree that the right of least privilege -- giving users access only to the data they need to do their job and no more -- is the appropriate level for users' access rights, they disagree on how to define the data itself. One way to identify data is comprehensive data classification. However, if a company has never classified any of its data, especially data that will be stored offsite in a cloud-based application or in cloud storage, it can be a massive, time-consuming job.

The argument for data classification is that if you don't have data classification, how do you implement data loss prevention, segregation of duties, and policies and procedures? The argument against classification is that if it is classified incorrectly, confidential data can be put at risk. Unfortunately, experience tells us it is easier to misclassify data than it is to be 100 percent correct.

Another challenge to classifying data is who does the classifying. If that task is left to the content creator, they might not be able to classify the data appropriately. For example, a low-level staffer at a company working on research about a competitor might not know that management is using that research as part of its mergers and acquisitions program. Therefore, the employee might not realize that they are working on a confidential program; they might simply think it is part of their routine work.

Without setting policies and procedures for each level of data, the foundation for all compliance walls and security are moot. Essentially it comes down to what you protect and how you protect it.

Protecting Service And Superuser Accounts
In addition to managing personnel identification and credentials, companies need to do a better job of managing the identity and credentials of computer systems on their network that talk to computer systems in the cloud. The service accounts installed on various servers can have their credentials stolen just as a human user can, so having multiple levels of authentication for computer-to-computer communications is as important, if not more important, than user-to-computer authentication.
This is because if a computer's service account credentials are stolen, it can be much harder to identify the breach. A user whose credentials log in from China, for example, can be flagged as a potential breach, but it is harder to identify a breached system that logs in with authorized credentials because often this process is preapproved by a systems administrator.

Administrative user credentials require similar controls to service accounts. Users with administrative credentials essentially have the power to do anything on a server. For that reason, it is important that records be kept of what these users do for accountability. Rules should be in place to create audit trails to track if someone with administrative rights takes certain actions that are automatically approved. The rules would flag another administrator to review the activity to ensure it was appropriate, essentially a checks and balance system, so that if an administrator's account were used to take an inappropriate action, another administrator would be able to view or perhaps rescind the action, based on how the company configures its rules.

Cloud computing, in many ways, is no different from local computing. While some security precautions are different -- few cloud providers allow companies to run penetration tests against cloud servers -- the basic security requirements still remain. Ensuring that only users who are authorized and authenticated to access the data get the access is a primary concern. Anything less is simply a serious vulnerability waiting to be exploited.

Toms It Pro,2-887.html
Powered by Blogger.