Archive

Posts Tagged ‘security’

My thoughts from the White House OSTP “Big Data” RFI

(1) What are the public policy implications of the collection, storage, analysis, and use of big data? For example, do the current U.S. policy framework and privacy proposals for protecting consumer privacy and government use of data adequately address issues raised by big data analytics?

Current policy is not sufficient to address big data issues. There are many good proposals, but the speed with which they are taking shape means they are being lapped by the constantly shifting realities of the technology they are meant to shape. NSTIC (National Strategy for Trusted Identities in Cyberspace http://is.gd/JOrjCw) has been an excellent example of this. That digital identity is core to properly addressing big data should be obvious. How can we hope to protect privacy if we cannot identify the proper steward of data? How can we identify data stewards if the people who ought to be identified have no consistent digital identity? The very founding notion of NSTIC, trusted identities, begs the question of if we are prepared to approach empowering people via assigning responsibility. If we do not have identities that can be trusted, then we don’t even have one of the basic building blocks that would be required to approach big data as a whole.

That said, the implications that big data has are too large to ignore. In “The Social, Cultural & Ethical Dimensions of Big Data” (http://is.gd/EGe7tD), Tim Hwang raised the notion that data is the basic element in (digital) understanding; and further that understanding can lead to influence. This is the big data formulation of the notion that knowledge leads to rights, and rights lead to power – the well tested idea of Michel Foucault. In the next century, the power of influence will go to those who have understanding culled from big data. This will be influence over elections, economies, social movements and the currency that will drive them all – attention. People create big data in what they do, but they also absorb huge amounts of data in doing so. The data that can win attention will win arguments. The data that gets seen will influence all choices. We see this on the internet today as people are most influenced not by what they read which is correct but rather what they see that holds their attention. And gaining that influence seems to be playing out as a winner takes all game. With nothing short of the ethical functioning of every aspect of human life on the line, big data policy implications cannot be understated.

(2) What types of uses of big data could measurably improve outcomes or productivity with further government action, funding, or research? What types of uses of big data raise the most public policy concerns? Are there specific sectors or types of uses that should receive more government and/or public attention?

The amount of data involved in some big data analysis and the startlingly complex statistical and mathematical methods used to power them give an air of fairness. After all, if it’s all real data powered by cold math, what influence could there be hiding in the conclusions? It is when big data is used to portray something as inherently fair, even just, that we need to be the most concerned. Any use of big data that is meant to make things “more fair” or “evenly balanced” should immediately provoke suspicion and incredulity. Just a small survey of current big data use shows this to be true. Corrine Yo from the Leadership Conference gave excellent examples of how surveillance is unevenly distributed in minority communities, driven by big data analysis of crime. Clay Shirky showed how even a small issue like assigning classes to students can be made to appear fair through statistics applied to big data when there are clearly human fingers tipping the scales. There are going to be human decisions and human prejudices built into every big data system for the foreseeable future. Policy needs to dictate what claims to fairness and justice can be made and outline how enforcement and transparency must be applied in order to be worthy of those claims.

The best way for government to speed the nation to ethical big data will be to fund things that will give us the building blocks of that system. In no particular order a non-exhaustive list of these ethical building blocks will be trusted identity, well defined ownership criteria of data generated by an individual directly and indirectly, simple and universal terms for consent to allow use of data, strong legal frameworks that protect data on behalf of citizens (even and especially from the government itself), and principles to guide the maintenance of this data over time, including addressing issues of human lifecycles (e.g. what happens to data about a person once they are dead?). There are many current proposals that apply here, e.g. NSTIC as mentioned above. All of these efforts could use more funding and focus.

(3) What technological trends or key technologies will affect the collection, storage, analysis and use of big data? Are there particularly promising technologies or new practices for safeguarding privacy while enabling effective uses of big data?

Encryption is often introduced as an effective means to protect rights in the use of data. While encryption will doubtless be part of any complete solution, today’s actual encryption is used too little and when used often presents too small a barrier for the computing power available to the determined. Improvements in encryption, such as quantum approaches, will surely be a boon to enforcement of any complete policy. The continued adoption of multi-factor authentication, now used in many consumer services, will also be an enabler to the type of strong identity controls that will be needed for a cooperative control framework between citizens and the multitude of entities that will want to use data about the citizens. As machines become better at dealing with fuzzy logic and processing natural language, there will be more opportunities to automate interactions between big data analysis and the subjects of that analysis. When machines can decide when they need to ask for permission and know how to both formulate and read responses to those questions in ways that favor the human mode of communication, there will be both more chances for meaningful decisions on the part of citizens and more easily understood records of those choices for later analysis and forensics.

(4) How should the policy frameworks or regulations for handling big data differ between the government and the private sector? Please be specific as to the type of entity and type of use (e.g., law enforcement, government services, commercial, academic research, etc.).

Policies governing interaction of government and private sector is one area where much of what is defined today can be reused. Conversely, where the system is abused today big data will multiply opportunities for abuse. For example, law enforcement data, big or not, should always require checks and balances of the judicial process. However, there is likely room for novel approaches where large sets of anonymized data produced from law enforcement could be made available to the private and educational sectors en masse as long as that larger availability is subject to some judicial check on behalf of the people in place of any individual citizen. Of course, this assumes a clear understanding of things being “anonymized” – one of many technical concepts that will need to be embedded in the jurisprudence to be applied in these circumstances. There are cracks in the current framework, though. This can allow data normally protected by regulations like HIPPA to seep out via business partners and other clearing house services that are given data for legitimate purposes but not regulated. All instances of data use at any scale must be brought under a clear and consistent policy framework if there is any hope to forge an ethical use of big data.

IdP risks, social engineering customer service, & Mat Honan

The blogosphere is on fire with tales of Mat Honan’s being hacked (does anyone say “blogosphere” anymore?). The source most seem to be pointing back to is Wired’s article. The best thing I’ve seen is my bud @NishantK‘s writeup where he breaks it all down. And I’m not just saying that because he points back to my own piece about IdPs and their risks relative to upcoming NSTIC style requirements. But that is part of why I’m writing this short piece. I won’t attempt to say again what others have no said very well about the #mathonenhack and what it means you should do (but I know I finally turned on Google two factor authentication – have you?). I would like to answer a question asked by Dave Kearns on twitter, though:

@dak3 question about IdP risk

@dak3 question about IdP risk

He was asking in the original context of the NSTIC comments. But I think it’s underlined by the eerie timing of discussing those risks and them watching this whole #mathonenhack play itself out in the media. In light of what happened and what it means for the risk and responsibility for an IdP, my answer stays the same. I don’t think NSTIC makes any IdP a bigger target then if they are already in the business of maintaining valuable assets for their own profit today. Later on, Dave also stated: “poor 3rd party IDP security practices means IT mgr (& CISOs) will draw the line.” There’s no doubt that there were some poor policies in place. And, as Nishant notes in his piece, Amazon and Apple have both changed some of that. But the key to making this happen comes down to the exploit of the brain of an Apple customer service rep when they decided that they would try to be helpful in the face of ambiguous results from their identity proofing procedures. Has that rep ever even been exposed to the concept of “identity proofing”? I can’t speak for Apple, but I’ve asked others and the answer has always been “no”. Apple in particular goes out of their way to be “friendly” when they can. Here it was used against them with terrible results. In the end, all the best process in the world can be exploited by getting to the right person and getting them to do the wrong thing for what they think is the right reason. At least, that will be true so long as we have people in the position to override our IAM systems.

Is the ID ecosystem #NSTIC wants too much risk for an IdP?

August 6, 2012 1 comment

I’m gearing up to go to the NSTIC convened steering group meeting in Chicago next week. Naturally, my inner nerd has me reviewing the founding documents, re-reading the NSTIC docs, and combing through the by laws that have been proposed (all fo which can be found here). I am also recalling all the conversations where NSTIC has come up. One trend emerges. Many people say they think the NSTIC identity provider responsibilities are too much risk for anyone to take on. With identity breaches so common now that only targets with star power make the news, there does seem to be some logic to that. If your firm was in the business of supplying government approved identities and you got hacked then you are in even hotter water, right?

The more it rolls around in my head, the more I think the answer is: not really. Let’s think about the types of organization that would get into this line of work. One that is often cited is a mobile phone provider. Another is a website with many members. One thing these two classes of organization – and most others I hear mentioned – have in common is that they are already taking on the risk of managing and owning identities for people. They already have the burden of the consequences in the case of a breach. Would having the government seal of approval make that any less or more risky? It’s hard to say at this stage, but I’m guessing not. It could lessen the impact in one sense because some of the “blame” would rub off on the certifying entity. “Yes, we got hacked – but we were totally up to the obviously flawed standard!” If people are using those credentials in many more places since NSTIC’s ID Ecosystem ushers in this era of interoperability (cue acoustic guitar playing kumbaya), then you could say the responsibility does increase because each breach is more damage. But the flipside of that is there will be more people watching, and part of what this should do is put in place better mechanisms for users to respond to that sort of thing. I hope this will not rely on users having to see some news about the breach and change a password as we see today.

This reminds me of conversations I have with clients and prospects about single sign on in the enterprise. An analogy, in the form of a question, a co-worker came up with is a good conversation piece: would you rather have a house with many poorly locked doors or one really strongly locked door? I like it because it does capture the spirit of the issues. Getting in one of the poorly locked doors may actually get you access to one of the more secure areas of the house behind one of the better locked doors because once you’re through one you may be able to more easily move around from the inside of the house. Some argue that with many doors there’s more work for the attacker. But the problem is that also means it’s more work for the user. They may end up just leaving all the doors unlocked rather than having to carry around that heavy keychain with all those keys and remember which is which. If they had only one door, they may even be willing to carry around two keys for that one door. And the user understands better that they are risking everything by not locking that one door versus having to train them that one of the ten doors they have to deal with is more important than the others. All of this is meant to say: having lots of passwords is really just a form of security through obscurity, and the one who you end up forcing to deal with that obscurity is the user. And we’ve seen how well they choose to deal with it. So it seems to me that less is more in this case. Less doors will mean more security. Mostly because the users will be more likely to participate.

“Security” is still seen as reactive controls & ignores IAM

There was an excellent article at Dark Reading the other day about data leaks focusing on insider threats. It did all the right things by pointing out “insiders have access to critical company information, and there are dozens of ways for them to steal it” and “these attacks can have significant impact” even though “insider threats represent only a fraction of all attacks–just 4%, according to Verizon’s 2012 Data Breach Investigations Report.” The article goes on to discuss how you can use gateways, DLP for at rest and in flight data, behavioral anomaly detection, and a few other technologies in a “layered approach using security controls at the network, host, and human levels.” I agree with every word.

Yet, there is one aspect of the controls that somehow escapes mention – letting a potentially powerful ally in this fight off the hook from any action. There is not one mention of proactive controls inside the applications and platforms that can be placed there by IAM. A great deal of insider access is inappropriate. Either it’s been accrued over time or granted as part of a lazy “make them look like that other person” approach to managing entitlements. And app-dev teams build their own version of security into each and every little application they pump out. They repeat mistakes, build silos, and fail to consume common data or correctly reflect corporate policies. If these problems with entitlement management and policy enforcement could be fixed at the application level, the threats any insider could pose would be proactively reduced by cutting off access to data they might try to steal in the first place. It’s even possible to design a system where the behavioral anomaly detection systems could be consulted before even handing data over to a user when some thresholds are breached during a transaction – in essence, catching the potential thief red handed.

Why do they get let off the hook? Because it’s easier to build walls, post guards, and gather intelligence than it is to climb right inside of the applications and business processes to fix the root causes. It’s easier to move the levers you have direct control over in IT rather than sit with the business and have the value conversation to make them change things in the business. It’s cheaper now to do the perimeter changes, regardless of the payoff – or costs – later. Again, this is not to indict the content of the article. It was absolutely correct about how people can and very likely will choose to address these threats. But I think every knows there are other ways that don’t get discussed as much because they are harder. In his XKCD comic entitled “The General Problem,” Randall Munroe says it best: “I find that when someone’s taking time to do something right in the present, they’re a perfectionist with no ability to prioritize, whereas when someone took time to do something right in the past, they’re a master artisan of great foresight.” I think what we need right now are some master artisans who are willing to take the heat today for better security tomorrow.

Categories: iam Tags: , , , , , ,

What I learned at @kuppingercole’s #EIC11: #identity #IAM #privacy and secrets

I must admit to being very selfish at this year’s EIC. Instead of going to the sessions that would likely have been most useful to Quest, I went to those that spoke most strongly to my own curiosities. The first thing I did was explore how vendors, users, and analysts feel about standards. It seems like it’s a chicken and egg subject – still. Users wait for vendors to adopt standards. Vendors wait for users and analysts to put force behind them. And in the mean time, only obvious success (SAML) and obvious need (XACML) seem to get standards investment and attention. The most interesting moment of this leg of the journey was when @OASISopen‘s Dr. Laurent Liscia asked from the keynote stage how many people in the audience were vendors to “make sure we’re not talking to ourselves.” Apparently we weren’t, but it was an interesting glimpse into how the whole notion is perceived even by those most dedicated to that cause of standards.

I also went to an absolutely fascinating deep dive into EU privacy and data protection law, which was hosted by Dr. Jörg Hladjk of Hunton & Williams LLP. Perhaps the most interesting thing I walked away with was a new sense of how fragile these protections really are. I think people in the US tend to think about these laws as being very intimidating and forceful. But that likely comes from the vastly complicated contract, audit, and procedure (paperwork) that is needed to deal with the laws. However, two shocking things became clear over the course of the day. First, any reasonable legal basis can be used as a basis to get at the data. A person can sign away all the protection in a single stroke – as anyone who agreed to the terms to get an iPhone in the EU has done in some part. And, because the framework is so much more comprehensive, things like a EULA, which is routinely cast aside in US cases since it’s seen as so flimsy, is much more forceful in the EU since the user is deemed to be so much better informed and protected by the framework. Second, there are cases where protections in the US are stronger than in the EU. A good example is when it comes to breech notification, where a data steward is forced to notify you of some event that may have compromised your PII. It seems that between NSTIC, efforts at the state level (like California’s new proposed “social media” law), and other things in the works, the US may actually come out ahead of the game in a practical sense within the decade.

The last lesson was a pleasant surprise: nearly all identity minded people are closet philosophers. Anyone reading this is likely to know my undergraduate (and only) degree is in philosophy, and perhaps also that I still indulge that impulse heavily as often as I can. Dr. Emilio Mordini, CEO of the Centre for Science, Society and Citizenship (CSSC), gave a keynote on the nature of secrets that was a HUGE hit. Not to say everyone agreed with all his views. In fact, @NishantK and @ggebel both took shots at his ideas from the same keynote stage later. The idea that drew the most criticism was Dr. Mordini’s very unpopular conclusion that one shouldn’t worry about securing data, but rather tracking data. He feels it’s less important to worry about keeping a secret than keeping track of who knows the secret. All of this flows from his central thesis that all secrets are Pulcinella secrets – not really secrets but rather, like a secret in a small town, something everyone knows but no one says so long as the parties involved have the power to motivate everyone to not say it in the town square. Tim Cole goes into all the details of the Pulcinella story on his own blog. The truth of all of it is left as an exercise for the reader. But the thing that made me happy was the abstract conversations in the hallways and bars for the rest of the conference as everyone digested the deeply interesting issues that were raised and what they meant in our shared context of identity, access, privacy, and technology.

Policy Translation – The Art of Access Control Transcends RBAC, ABAC, etc.

After some holidays, lots of internal meetings, and some insane travel schedules, things are settling back down this week just in time for me to head to TEC. So I can get back to spending time with Quest’s customers, partners, and having great discussions with people. In the last week, I had three excellent conversations, one with a panel of folks moderated by Martin Kuppinger from Kuppinger & Cole set up by ETM [link to podcast site], another with Don Jones and an audience of folks asking questions set up by redmondmag.com [link to webcast], and the third just today with Randy Franklin Smith [link to webinar site]. All these discussions revolved around managing identity (of course); they focused on the business’s view of IAM, wrapping proper security controls around Active Directory, and controlling privileged user access, respectively. Even though the subjects seemed quite far apart, a common question emerged: how do you translate the policy the business has in mind (or the auditor has in mind) into something actionable which can be enforced through a technical control? Put another way, the problem is how to take wishes expressed in business terms and make the come true with technology. To me, this is the central question in the IAM world. We have many ways to enforce controls, many ways to create compound rules, many ways to record and manage policies. But the jump from a policy to a rule is the tricky bit.

Let’s take an example and see what we can do with it. Everyone in the US and many around the world know SOX, and most that know it are familiar with section 404. There is a great wikipedia article about SOX section 404 if you want to brush up. Section 404 makes the statement that it is “the responsibility of management for establishing and maintaining an adequate internal control structure and procedures for financial reporting.” While this makes sense, it’s hardly actionable. And businesses in the US have relied on many layers of committees and associations to distill this. What is that process? It’s lawyers and similarly minded folks figuring out what executives can be charged for if they don’t do things correctly in the face of vague statements like the one above. So they come up with less and less vague statements until they have something they feel is actionable. Of course, what they feel is actionable and what some specific IT department sees as actionable may be quite different.

From the filtering at the high levels of the interbusiness activities you get a statement like “Understand the flow of transactions, including IT aspects, sufficient enough to identify points at which a misstatement could arise,” which comes from the work done by the SEC and POCAB to interpret SOX section 404. That approaches something IT can dig into, but it’s hardly actionable as is. But now a business can take that, bring it inside the organization, and have their executive management and IT work out what it means to them. Of course, there are scads of consultancies, vendors, and others who would love to assist there. Your results may vary when it comes to those folks, or your own folks, being able to make these statements more or less actionable. With this specific statement about the “flow” of data and not allowing “misstatement” to arise, there is general agreement that having IT staff with administrative powers that could, in theory, alter financial data is a risk that needs to have a control. And from that general agreement has risen an entire market for privileged access management products that allow you to restrict people who need administrative rights to do operational tasks in IT infrastructure from using those rights to somehow change data that would be used in any kind of financial reporting (or use that access to do any number of other things covered by other sections of SOX or other regulations like PCI, etc.).

What should be apparent is that things like RBAC, ABAC, and rules based approaches to access control are all simple and straightforward when compared to taking policy and making it actionable. Putting an RBAC system into place is taking action. But, as anyone who has been through an RBAC roll out will tell you, the hardest bit is figuring out the roles. And figuring out the roles is all about interpreting policies. So what is the answer for all those folks on these webcasts who wanted to know how to master this art? The short answer is like the old joke about how you get to Carnegie Hall: practice. The medium length answer is to find a consultancy and a vendor that you trust and that have had the right amount of practice and make them do it for you. The long answer is to follow the path I took above trying to explain the question. You need to analyze the requirements, break them down, and keep doing that until you start getting statements that look slightly actionable. Of course, that takes a huge amount of resources, as evidenced by all the money that’s been spent on SOX alone in the US (that same wikipedia article quotes one study that says the cost may have been 1.7 trillion USD). And the final trick is to take your actions and breakdowns back to the top, your auditor or CISO or whomever started the chain, and validate them. That’s a step that gets skipped all too often. And then you see million dollar projects fail with one stroke of an auditor’s pen.

RSA Conference (#RSAC) Highlights

March 4, 2010 Comments off

Overall, the conversations at RSA have been more focused this year than last. Most people came asking project focused questions. The most popular was two factor, of course. Many asked about auditing, some about SSO and the rest asked about controlling directory content and delegation for SoD. So I’ve been talking a lot about Defender, InTrust, Authentication Services and ActiveRoles Server, respectively. It also seems like there are more senior people here this year. Many titles with director, VP and executive in them are speaking to us. I think it’s a sign of how much more seriously identity and security are being taken now.

The biggest a-ha moment for me so far was sitting in the IDC breakfast yesterday. Sally Hudson from IDC was talking about the penetration of identity and access management technologies into applications. She mentioned how most of the technologies, SSO, TFA, etc, were not new but were only now starting to become part of the majority of applications. What occurred to me was only now is identity technology getting to the point where applications can easily consume its services. Pieces that are easy to use have great penetration, which accounts for the success of LDAP and products like Site Minder. But for more advanced identity that incorporates federation capabilities, provisioning integration, fine grained access control and other advanced functions, it’s only now that we’re seeing technologies deliver. And it’s not that applications don’t do these things now. Applications that need to federate do, applications that need access control have it. Those services are built on demand and typically without COTS help, though. With the rise of standards and the maturity of application ready toolkits and protocols, now the application teams themselves and business groups they aim to please are thinking about these things as features they would like to have for any application not just stuff with identified, immediate needs. My experience is that when the applications want it, that’s when the market is real. That time may have finally come.

Another cool thing for me was meeting some of our partners face to face. Especially cool was getting a new visual aid from our friends at NagraID Security. I’ve been pushing the idea of multi-function multi-facto devices for a long time. Now I have a working one to use as a visual aid in meetings. It has a smart card chip, OTP capabilities by pressing a button on the front, a picture printed and two different scan spots (barcode and box). I can’t wait to break it out in my next meeting with a client. I’ve already been showing it off on the show floor.
Front of NagraID multi-function multi-factor card
Back of NagraID multi-function multi-factor card

%d bloggers like this: