Insights into Authentication, Identity Management and Trusted Access
|
Wednesday, June 23, 2010 Vulnerability Assessment — Do You Know Who Is Accessing Your Data? by Anna Slomovic, Anakam CPO When the ash cloud from Eyjafjallajokull volcano caused the closure of vast portions of European air space in April 2010, hundreds of thousands of people found themselves stranded in places where they had not expected to be. Many of them started working from wherever they were—hotels, friends’ homes, Internet cafes, and airport hotspots. Even the Norwegian prime minister was working remotely from the airport when he could not get home after attending President Obama’s nuclear summit. Clearly, teleworking is no longer a capability that needs to be available to a few staff members with predictable telecommuting arrangements, but something that can be and should be available to a variety of workers in many situations. In addition to providing convenience and increased productivity, telework is also an important part of corporate business continuity and disaster recovery plans. However, letting workers access sensitive systems and data from unpredictable locations and, potentially, using uncontrolled devices raises a host of privacy and security concerns. Organizations remain accountable for data protection whether their data resides behind corporate firewalls or in the cloud, and regardless of the method by which the data is accessed. Analyzing potential attack vectors related to remote access, identifying vulnerabilities, and implementing solutions to minimize risk of compromise is an essential part of securing systems and networks. The threats and potential vulnerabilities involving credentials used to access corporate networks and view or transact business with corporate data need to be addressed along with more traditional defense assessments. Tracking who has access to organizational networks, systems and data—and being able to prove this in a way that is difficult or impossible to repudiate—is an important component of operating a secure computing environment. Yet, in spite of repeated news coverage about the ease with which usernames and passwords are compromised, many organizations continue to rely on this type of credential for remote access, even when systems and data are strategically important to the company or involve sensitive personal information of employees and customers. Weak authentication credentials are a significant security vulnerability even when enterprises require transactions to be conducted over an encrypted connection, and even if they permit users to access the corporate network only from company-issued “locked down” devices. The problem is that once the enterprise accepts a user’s login credentials, the rights and privileges associated with those credentials allow the user to see data and to perform transactions with that data to the extent of his or her privileges in the system. This data may include personal data such as web mail, personal health records, or tax data. If the remote access is afforded to those with higher level privileges like healthcare providers, tax preparers, or employees within the enterprise, they would have access to an even broader data set. Fraudsters may get only gibberish by eavesdropping on an encrypted transmission, and they may only get encrypted gibberish if they manage to get through enterprise “back-door” defenses, but if they steal or guess user credentials, they arrive at the front door with the key that allows them enter an account, view its unencrypted contents and perform transactions with the data. In many cases, fraudsters do not really care whose account they hijack as long as they can get into a system and then use that entry to give themselves more rights and privileges. Since fraudsters would be using legitimate credentials, organizations may not even know that their systems or networks have been compromised because they think that only legitimate users have gained access. The problem is made worse by the fact that many people use the same username and password (often a publicly available or easily guessable e-mail address) over and over, making it easier for themselves to remember their login credentials and making is very easy for someone to compromise several accounts without additional effort. Usernames and passwords can be attacked through multiple vectors. These credentials can be stolen by installing malware on the user’s device, such as key loggers that snoop on user data entry and then send the information to thieves, or Trojans that facilitate man-in-the-middle attacks. Malware is now so common and so sophisticated that users are often advised not to access their bank accounts or sensitive systems from public computers. Another attack vector on usernames and passwords is phishing or smishing, i.e., sending an email or text message (SMS) that directs a user to a fraudulent web site and tricks him into entering credentials. Once the thief has the credentials, however they may have been obtained, he has the ability to enter networks or systems through the front door. To mitigate the weakness of usernames and passwords, some companies have adopted strong two-factor authentication. In addition to requiring a username and password (something a user knows), strong authentication involves the use of a token (something a user has) or a biometric (something a user is). When two-factor authentication is used, stealing a username and password is not sufficient to gain access without also stealing and entering the second factor passcode within its limited validity period. There are many modalities for providing this second factor passcode, and these vary in convenience and usability for the user and expense for the enterprise. Having multiple approaches to two-factor authentication permits the enterprise to maintain network security in a variety of circumstances, even ones as unpredictable as disasters that strike without warning. For example, the use of a smartcard may be fine when someone is working from an office computer with a card reader, but would not work for remote access from an Internet café. A number-generating token would work with any computer, but only if the individual has that token at the time he or she requires access. Receiving a passcode via SMS is convenient and does not require the individual to carry around anything other than his cell phone, but it does require cell reception. Technology is available that permits on-the-fly selection among multiple modalities for receiving a second factor authenticator. This kind of versatility in a single, integrated platform allows organizations and their employees to derive maximum benefit from telework while maintain security of their networks, systems, and data. |
|
Friday, April 2, 2010 Privacy and Consent in Patient Health Information by Anna Slomovic, Anakam CPO The growing scale of electronic health information exchange has brought us face-to-face with the question about the extent to which patient should be able to control access to their health information. With paper records patients could decide to not tell one doctor about other doctors they were seeing, or not to tell one doctor what medications were prescribed for them by other doctors. This is being fundamentally changed by the ability to search for electronic health information and then collect and collate it. Read More |
|
Wednesday, March 10, 2010 Don’t Put the Key Under the Mat – Authentication AND Encryption Working Together by Anna Slomovic, Anakam CPO In order to prevent different types of attacks against usernames and passwords, organizations have made the login process more difficult--passwords have become more complex, additional “security questions” have become part of the process, and some organizations have moved toward two-factor authentication either because they are required to do so by regulation or because they find the risk of unauthorized access to be too high for the type of data they house. Read More |
|
Tuesday, February 16, 2010 Patient Identity and Health IT by Dr. Bill Braithwaite, Anakam CMO Having a way to represent the identity of a patient in electronic transactions when the patient is not present is critical. According to the HIPAA Privacy Rule, there are at least 17 data elements that can be used to identify a patient that must be removed before a medical record can be considered ‘de-identified’. It is essential that the data that represents the patient be accurately matched to the person who is the subject of this data across all records about that person. Read More |
|
Friday, February 12, 2010 Telework and Corporate Security by Jose Jimenez, Anakam Sr. Director, Health Information Technology In February 2010, Federal Government offices in Washington, D.C. closed for four days because of an historic snowfall in the Washington-Baltimore region. Last fall, President Obama declared the H1N1 flu pandemic a national emergency. These extreme examples and many other more ordinary ones highlight the importance of teleworking in today’s connected environment. Read More |
|
Wednesday, February 10, 2010 Secrets and Authentication by Anna Slomovic, Anakam CPO Five to ten years ago, little known facts about our lives were widely used for authentication before we were permitted access to sensitive information. Quite often the question was, “What was your mother’s maiden name?” This was a “shared secret” model of authentication. Over time, as more organizations use the same facts in various contexts, “shared secrets” become much less secret. Read More |
|
Monday, January 25, 2010 Authentication and Electronic Signatures by Anna Slomovic, Anakam CPO An interesting court case was recently sent for trial in New York federal court. The case revolves around an appropriate level of authentication for an individual who electronically signed an insurance application. Read More |
|
Thursday, January 14, 2010 Authenticating Password Re-sets by Anna Slomovic, Anakam CPO In the past few days Google has announced that its Gmail system suffered an attack in which the Chinese authorities apparently tried to gain information about activities of human rights activists. In its corporate blog, Google posted information about the attack and about how it is responding. Interestingly, some of the accounts were accessed not through a security breach at Google but through a misuse of Gmail credentials. Read More |
|
Wednesday, January 6, 2010 Proposed Rule on the Electronic Health Record Incentive Program by Anna Slomovic, Anakam CPO On December 30, 2009, the Centers for Medicare & Medicaid Services issued the Proposed Rule on the Electronic Health Record Incentive Program. Together with the Interim Final Rule on Health Information Technology, they provide an initial view into the approach that the Department of Health and Human Services is taking toward ensuring that health information technology will provide privacy and security protections to individuals’ sensitive health information. Read More |
|
Monday, January 4, 2010 Welcome to the Anakam Blog by Allan Camaisa, Anakam CEO Truly transformational eGovernment is happening, health information sharing standards are solidifying and true sharing of sensitive information is gaining momentum, and major new security and privacy regulations have been announced to better enable trusted information access through the Web. Anakam launched this blog to discuss all of these issues and many others in an interactive dialog with our partners, clients, and the broader privacy, security, and identity management communities. Read More |
Vulnerability Assessment — Do You Know Who Is Accessing Your Data? April 2, 2010
Privacy and Consent in Patient Health Information March 10, 2010
Don’t Put the Key Under the Mat – Authentication AND Encryption Working Together February 16, 2010
Patient Identity and Health IT February 12, 2010
Telework and Corporate Security
Authentication and Electronic Signatures January 29, 2010
Multiple First Factor Questions Do Not Equal Multi-factor Authentication January 6, 2010
Proposed Rule on the Electronic Health Record Incentive Program February 10, 2010
Secrets and Authentication February 22, 2010
Understanding the Identity Lifecycle—Part 2