Posted by Robbie Forkish on Fri, Oct 30, 2009
A new white paper,
Cloud Computing: Business Benefits with Security, Governance and Assurance Perspectives, has just been published by
ISACA. The paper provides a short overview of cloud service models and deployment models, and lists the well-known business benefits of cloud computing -- with cost savings at the head of the list. Ease of deployment, high availability, scalability, efficiency and resiliency round out the list of cloud computing benefits.
But what's interesting to IT and security professionals are the risks and security concerns associated with cloud computing. To those following the literature and debates on cloud security the concerns listed in the white paper are familiar: what is the reputation, history and sustainability of the cloud service provider (CSP); where does data reside, and does it matter if that question can't be answered precisely; how well is information protected; who can have access to sensitive or confidential information; and can sensitive information be located in the event of a disaster. Many of these issues at a minimum can be addressed in contractual service level agreements (SLAs), but writing tight SLAs is not the same as mitigating risk.
The ISACA white paper is relatively brief and high-level. Many other information resources exist that delve into great detail on CSP exposures and vulnerabilities, both real and imagined. But additional detail and technical depth isn't necessarily what organizations need to determine whether cloud benefits outweigh the risks for their situation. Specifically, they need to assess the risk related to their sensitive data that would be operated on or stored in the cloud.
Every organization should -- and many organizations do -- have a data classification strategy in place. COBIT 4.1, for example, mandates that organizations should "Establish a classification scheme that applies throughout the enterprise, based on the criticality and sensitivity (e.g., public, confidential, top secret) of enterprise data... It is used as the basis for applying controls such as access controls, archiving or encryption" (section PO2.3). The following classification guide, from the State of New York's CSCIC, is a good example of an approach for classifying data based on risk levels with regard to data confidentiality, integrity and availability:
Here is another approach, then, to dealing with cloud security risks: Limit cloud-based applications to only those that operate on low- or moderate-risk data. Put another way, your organization may decide to reap the economic benefits of cloud-based services -- but only for applications that fall within acceptably low risk profiles.
This evaluation process is already being employed, if only implicitly. Tens of thousands of companies have opted for SaaS-based CRM solutions, the most well-known being from Salesforce.com. Customer information, while valuable to the organization, is not so critical that having it stored in the cloud is viewed as an unacceptably high risk.
On the other hand, many companies I've spoken to believe that the risk of storing personal identifying information (PII) or other highly-confidential information in the cloud is unacceptably high-at least at the current level of cloud security maturity.
My company, Cloud Compliance, has a keen interest in this question. We believe that internal user names and logon activity are no more sensitive than CRM data currently being stored in the cloud by so many companies. While we've found many organizations that agree with our risk assessment, there are others who aren't so sure.
Identity and Access Assessment (IdAA) solutions such as that being developed by Cloud Compliance need to upload two data sets to the cloud in order to perform their analytics:
- log records from SSO systems, log management systems or from application servers which show all access activity (log on and log off) and includes user IDs and time/date of access; and
- rights or entitlement information from AD, the applications or from an identity management system which lists which users have entitlements to which applications. (Note that if the entitlement/identity management system includes personal identifying information such as SSN or home address it is not included in data sent to the cloud. Also note that data in transit as well as data at rest is encrypted.)
(Please visit our product page for more information on how our solution works as well as a use case demo.)
This is the relevant risk management question: If you assume that IdAA solutions reduce if not prevent audit findings related to access controls, is it worth the risk to have your user names, login activity and entitlement information stored in the cloud?
Here's another way to look at it: Is your internal entitlement and activity data more or less sensitive than your customer data that's being stored in the cloud by Salesforce.com and other CRM SaaS solutions?
I am very interested in your views. Please leave a comment on the blog, or send me your opinion at rforkish@cloud-compliance.com. I'll report back in a future post on the collective wisdom of the blog readers.
Posted by Robbie Forkish on Fri, Oct 23, 2009
I recently ran across an article by Paul Smocer of BITS entitled "The Future of Banking Enterprise Access Management & Authentication" in Security Strategies in which he discusses the four component areas of IAM, and the challenges facing each. Smocer defines the four aspects of IAM as follows:
- Enrollment/Identification -- Assigning a "persona" to employees
- Authentication -- Validating the employee is legitimate
- Provisioning -- Assigning and rescinding "rights" to an employee
- Review/Monitoring -- Ongoing and periodic validation of users and their rights.
Enrollment/Identification. The largest challenge here is establishing and maintaining a common set of user ID's from disparate systems. In general, the more legacy systems, the larger the challenge. And the challenge grows to the extent the organization has a higher rate of "joiners" and "leavers".
Authentication.The challenges in authentication simply have to do with the diversity of authentication methodologies and structures, which imposes additional resource requirements to manage.
Provisioning. The act of provisioning rights to users to allow access to specific systems' functions seems straightforward enough. The focus in most organizations is on the speed with which rights (also called privileges, or entitlements) can be assigned. Delays impact productivity! But as Smocer points out, deprovisioning rights also presents a challenge:
"An employee who has rights he or she no longer needs presents a threat in terms of data exposure, data loss or fraud."
Some organizations have begun to move to role-based access control (RBAC) processes, but they only work well where the environment is static or large groups have common access requirements. And for dynamic organizations?
"Where there is a diversity of roles and/or a diversity of access requirements, [RBAC] processes often fall short."
So, failure to deprovision rights can present a threat, but the recommended RBAC processes to manage this risk aren't effective where there is a diversity of roles and/or of access requirements. How, then, should such an organization deal with the provisioning challenge? The article doesn't say. But we do know one thing: this must be happening at a large number of organizations, because excessive access rights has been the top audit finding for each of the past two years.
Review/Monitoring. A key challenge in this area is that many provisioning systems require the line of business manager to validate the accuracy of entitlements. This is often a low priority for a busy business manager, who often makes the issue go away by rubber-stamping the current entitlement assignments. Another problem with relying on the user's manager to provision and deprovision rights is that many enterprises have adopted matrix organizational structure where there's no single manager to assess entitlement requirements and integrity as reported by Dartmouth researchers. Better review and monitoring of entitlements is clearly required, due to the known deficiencies of the provisioning processes and underscored by the high rate of audit findings.
What can be done? Cloud Compliance is developing an Identity and Access Control (IdAA) solution to address key challenges with IAM processes, especially in the areas of provisioning and review/monitoring. We identify users who have rights they no longer need, and provide tools for isolating high levels of over-entitlement by group, business unit or by application. Such tools enable root cause identification, and provide the necessary insight for remediation and process improvement. Furthermore, due to our global visibility as a cloud-based SaaS solution, we capture statistics industry-wide that our customers can access for setting their own policy benchmarks. Finally, in contrast to role-based access control systems, the Cloud Compliance SaaS solution requires no software to install, maintain and operate, no appliances to deploy, no consultants, advisors or professional services to deploy, and no huge upfront capital expense to incur.
Posted by Robbie Forkish on Thu, Oct 15, 2009
I went to an informative "Cornerstones of Trust 2009" conference yesterday in San Mateo, CA. One of the sessions I attended was "Compliance is Not The Same as Security!". It's an important topic, especially for IT/security staff facing challenges getting their security initiatives funded during these tough economic times.
There was a theme that ran throughout the session which I can summarize as this: "CEOs are being short-sighted by not investing in the [fill in the blank] security initiative. Don't they realize that a breach is inevitable, given enough time? And the cost of the [fill in the blank] security initiative is much, much lower than the cost of dealing with a breach (estimated at over $200 per record). Not to mention that preventing said breach provides other tangible and intangible benefits including protecting the brand, preventing customer erosion due to loss of trust, and avoiding a calamitous drop in stock prices."
Given the compelling case for securing the enterprise, why do CEOs fail to invest more in security solutions? Does this simply represent a failure of IT and security staff to make a compelling business case? Or are the CEOs in fact being short-sighted?
Let's try looking at this from the CEO's perspective. He or she is continuously under scrutiny by Wall Street, and the most common measure of the CEO's and the company's performance is by comparing various financial metrics to a relevant peer group, typically the company's competitors and other players in the same industry. Investors want to know - especially in an economic downturn - whether the CEO is keeping expenses in line. In other words, does the company spend a higher percentage in any category than peer company XYZ? If so, is there a measurable ROI from this higher rate of spending? If not, it looks to an investor like wasteful spending or lack of discipline. How should a CEO respond to that?
Risk management is the only rational way to frame the debate. But now we've entered the world of probabilities and risk assessments. What we know to be true is that no amount of spending can guarantee there will be no breaches. The management decision is one of making rational trade-offs between the probability of an event, and the cost of reducing that possibility - but not eliminating it.
In recent years, a new dimension has entered the debate: compliance. Regulatory standards apply now to public companies (SOX), healthcare (HIPAA), card handlers and retail (PCI), various aspects of financial services (primarily GLBA, but including the entire range of FFIEC audits), and other sectors. Most companies therefore have a mandatory level of security that's required in order to meet compliance requirements; failure to do so results in audit findings, and possible material weakness reports. No CEO wants that.
Security spending for compliance, then, is a given. And while compliance spending may not comprehensively protect the enterprise against a breach, it does provide one important bit of protection: liability. From the CEO's perspective, while the cost per record of responding to a breach may be high, it's nowhere near the potential cost of lawsuits resulting from said breach. And achieving compliance appears to provide a liability shield.
Therefore, the CEO thought process might go something like this: Security spending for compliance is mandatory. And while additional security-related spending might make us more secure, it doesn't add anything in terms of liability protection. Furthermore, there's no guarantee that additional security spending will prevent a breach, but there's a strong likelihood that it will increase spending compared to industry benchmarks. By spending on compliance we are protected against the biggest exposure, which is legal liability. It's not perfect, but given the pressure on margins it will have to do.
If compliance standards are strengthened, then of course the company - as well as all of its competitors - will increase spending to comply. And there's plenty of room for improvement in reducing IT audit findings; see here and here to read about top IT audit findings.
Cloud Compliance is developing an Identity and Access Control (IdAA) solution to improve the efficacy of compliance solutions, and reduce the cost of achieving compliance. Due to our global visibility as a cloud-based SaaS solution, we capture statistics industry-wide that our customers can access for setting their own policy benchmarks and ensuring that their security spending is in line with their peers. Finally, in contrast to most identity management systems, the Cloud Compliance SaaS solution requires no software to install, maintain and operate, no appliances to deploy, no consultants, advisors or professional services to deploy, and no huge upfront capital expense to incur.
Posted by Robbie Forkish on Thu, Oct 08, 2009
It should come as no surprise that the current economic climate has increased the risk of fraud from insiders. But the degree to which the insider threat problem has increased is a surprise, as described in a Dark Reading article
Bankers Gone Bad: Financial Crisis Making The Threat Worse. According to a new survey by Actimize, nearly 80 percent of financial institutions worldwide say the insider threat problem has increased in the wake of the economic downturn. Only 28 percent of financial institutions had not suffered an insider breach in the past 12 months (not including the breaches we don't yet know about).
How do insiders commit fraud? The profile of the bank fraudster that typically commits these crimes is a trusted, full-time employee, one who is well-versed in its operations and how to circumvent them and remain under the radar. And a favorite method is to use a dormant account resulting from excessive user entitlements:
"Some security measures for limiting user access to sensitive data, such as minimizing user privileges, don't apply cleanly for banks... The best thing they can do is proactively monitor and look for signs that user entitlements aren't being abused."
If looking for signs that user entitlements aren't being abused was possible, everyone would do it, right? Well, it has to be cheap, too: according to the survey, the biggest single challenge to meeting the threat is the cost of doing so.
In the past 12 months, 70 percent of financial institutions say they have experienced a case of data theft by one of their employees. Nearly half of the banks in the Actimize survey say they are losing 1% to 4% -- four percent! -- of their total revenues to insider fraud. With that as incentive, the most plausible explanation for failing to prevent fraud resulting from excessive user entitlements is that banks don't know how. What they do know is that perfect access control isn't possible, and that Identity Management (IdM) systems combined with manual reviews still fails to identify many excessive entitlements.
And they also know that excessive entitlements (also known as excessive access rights) was the top audit finding for the past two years.
Cloud Compliance is developing an Identity and Access Assessment (IdAA) solution to manage entitlements (also called privileges, or access rights). We identify users with excess entitlements, and provide tools for isolating high levels of over-entitlement by group, business unit or by application. Such tools enable root cause identification, and provide the necessary insight for remediation and process improvement. Furthermore, due to our global visibility as a cloud-based SaaS solution, we capture statistics industry-wide that our customers can access for setting their own policy benchmarks. Finally, the Cloud Compliance SaaS solution requires no software to install, maintain and operate, no appliances to deploy, no consultants, advisors or professional services to deploy, and no huge upfront capital expense to incur.
Posted by Robbie Forkish on Fri, Sep 18, 2009
Bruce Schneier, the Chief Security Technology Officer of BT and a highly regarded security guru, engaged in a point/counter-point debate with
Marcus Ranum in an
Information Security Magazine article entitled
Schneier-Ranum Face-Off: Is Perfect Access Control Possible?The question is particularly relevant today, especially in light of the fact that, as I've reported here and here, excessive access rights were the top audit finding over the past two years. Why is that? The general consensus is that organizations should implement a role-based access control (RBAC) system to manage entitlements. But as Schneier points out:
RBAC is very hard to implement correctly. Organizations generally don't even know who has what role. The employee doesn't know, the boss doesn't know--and these days the employee might have more than one boss -- and senior management certainly doesn't know.
Ranum seems to argue that at least part of the problem is that we're paying for decisions made over the past decade to make critical data easier to access and where it can be managed more cheaply, and that many of these decisions were incompetent and negligent.
What both Schneier and Ranum agree on is that over-entitlement is the norm today, and these excess entitlements -- also called excessive access rights -- represent a security and compliance exposure.
So where does that leave us? Based on what I've seen and the customers I've spoken to, I have to agree with Schneier's assessment:
In the end, a perfect access control system just isn't possible; organizations are simply too chaotic for it to work.
If RBAC systems are so hard to implement correctly, and even if doing so still leaves the organization with excessive access rights and their associated risks and vulnerabilities, what can be done? As I've suggested in my prior post, user activity monitoring in the form of an Identity and Access Control solution can complement RBAC identity management systems by providing feedback that uncovers excess entitlement in the form of dormant (aka zombie) accounts. Therefore, even if RBAC is very hard to implement correctly, and a perfect access control system just isn't possible, at least the organization can gain visibility into and remove the vulnerabilities and compliance exposure associated with excessive access rights.
Cloud Compliance is developing an Identity and Access Control (IdAA) solution as referred to above. We identify dormant accounts, and provide tools for isolating high rates of dormancy by group, business unit or by application. Such tools enable root cause identification, and provide the necessary insight for remediation and process improvement. Furthermore, due to our global visibility as a cloud-based SaaS solution, we capture statistics industry-wide that our customers can access for setting their own policy benchmarks. Finally, in contrast to software-based IdM solutions, the Cloud Compliance SaaS solution requires no software to install, maintain and operate, no appliances to deploy, no consultants, advisors or professional services to deploy, and no huge upfront capital expense to incur.