ATMs (otherwise known as a Cash Points, Money Machines, Cashlines or sometimes even Holes in the Wall), are a staple of modern life. To the everyday consumer, they are seen as a convenient way to access our bank accounts, even when the branch is closed.  (I remember standing in line at the bank as a child on Saturday mornings with my father so that he could withdrawal the funds our family needed for the week – talk about advanced planning!)  ATMs enable us to get our cash on demand, for those of us who still use cash, and have come a long way since the first machines in the 1960s which dispersed a set amount of funds and sent back the bank card at a later date.

Convenient to consumers, yes – but to fraudsters, ATMs are seen as a way to get their hands on currency that isn’t theirs and unlike an online transaction can be harder to trace.   As a cash-out point for many scams, fraudulent crimes and cyber-attacks the ATM has seen its fair share of unfriendly withdrawals.

Underground Card Marketplace (Source: RSA Anti-Fraud Command Center)

Fraudsters will typically purchase cards and PINs in the underground or recreate plastic cards using the stolen data from card skimmers (Krebs on Security has some great information on ATM Skimmers).  They will then recruit mules who are the feet on the street that take a cut of every withdrawal they make with the stolen data from ATMs.  Mule recruitment is pretty easy as there are plenty of people looking for quick cash, especially when the unemployment rate is high.

There is an entire ecosystem of criminals who specialize in one or more areas of the carders market.  Mules are recruited by Mule Herders who provide forged plastic cards from Forgers who bought credit card credentials from Traders who bought the compromised credentials from a Fraudster who specializes in hacking into payment systems or social engineering schemes such as phishing.  Each criminal makes money from some point of the chain and continues to feed into the underground economy with their specialty.  Kevin Poulsen’s King Pin describes one Hacker’s (Max Butler) plan to rule the black market in stolen credit cards before his crime ring was taken down by the FBI in 2007.

Source: WIRED

Last week the US Department of Justice published an indictment of a cybercriminal gang who used the ATM as the cash out point for a massive global heist – ultimately draining $45M from around the world.  The attackers used “sophisticated intrusion techniques” to hack into the information systems of payment processors and global financial institutions, steal prepaid debit card information and modify withdrawal limits.  The hacked prepaid debit card numbers and pins were distributed to fraudsters in 26 countries who encoded magnetic stripe cards with the compromised card data and withdrew cash from ATMs on a massive scale across the globe.

It is important to note that the prepaid cards used in this attack are typically pre-loaded with a limited amount and are not associated with a specific user account.  These cards lack transaction history and individual behavior patterns which most organizations leverage to monitor fraud.  This is one of the reasons these criminals targeted prepaid cards – they understand the payment ecosystem and exploit areas of weakness. For example if a mule went from ATM to ATM with a stolen genuine debit card associated to an account a transaction monitoring system could have flagged that activity as fraud.  However, with a prepaid card there is no association, transaction or behavioral history.

This latest heist is a reminder that old tried and true attacks will continue to occur without the correct cross channel risk based, intelligent security in place.  Yes, processers need to better protect themselves from breaches and understand the threats their networks face – before an attack occurs, not only after the fact.  But banks need to better understand the transactions that occur at the ATM, online and via their mobile banking to monitor risk and look for anomalous behavior across all channels. For example, if there is an anomaly in withdrawal amount or a large velocity of ATM activity over a short period of time, a risk based authentication system should flag the activity as high risk and create for further investigation.  (It remains to be seen how the roll out of CHIP /PIN based on the EMV protocol will affect card fraud in the US – where ~ 80% of all ATM fraud occurs – but that is a discussion for another day).

RSA Adaptive Authentication ATM Module enables organizations to analyze transactions in the ATM channel using Risk Based Authentication and cross channel fraud detection.  Fraudsters will continue to use the ATM channel to get their hands on cash, and we will continue to stay on top of the attack vectors in this space to provide intelligent controls to protect the end user.

Amy Blackshaw is a Principal Product Marketing Manager within RSA’s Identity and Data Protection Group. In her role, Amy is responsible for the go-to-market strategy for the RSA Adaptive Authentication solution which provides protection against advanced threats in the enterprise and online. Prior to joining RSA, Amy worked in the Energy Industry bringing secure technology solutions for sustainable energy businesses. Amy holds her undergraduate degree from the University of Massachusetts, Amherst, her MBA from Simmons College, and is a CISSP.

• 

In light of the recent events I’ve reflected on how valuable electronic health records (EHR) and health information exchange (HIE) participation can be in a time of crisis to immediately access critical life saving data on impacted victims.  EHRs not only allow for first responders to quickly access victims’ healthcare information, but also allows for more accurate ambulatory, ER and clinical decision making in life or death situations.

Accompanying the increase of business efficiency and convenience delivered with EHRs, organizations must also maintain concern about privacy, secure access, fraud and the growing cost of security breaches. However, too often in the mix of the chaos we tend to forget how important it is to secure electronic health information during these types of incidents to mitigate the potential risk of theft and non compliance to relevant regulatory requirements. Healthcare (and law enforcement) organizations need to ensure that all first responders, staff members – and volunteers who have access to patient information must be educated and in compliance with their security and privacy policies so that it is not inappropriately leaked to media and even worse used by fraudsters looking to capitalize on a tragedy.

The Healthcare Information Security Today survey, sponsored by RSA, highlights what healthcare organizations are taking into consideration to comply with the HIPAA Omnibus Rule.  The survey shows that most organization’s top security priorities are preventing and detecting breaches, improving regulatory compliance and improving security training.    Also, it reveals that one of the biggest perceived security threats for healthcare organizations is the growing use of mobile devices and business associates taking inadequate security precautions; only 32% of survey respondents expressed confidence in security controls of their BAs and as you can see on the HHS “wall of shame”, a majority of breaches were caused by lost or stolen devices or misplaced laptops.

Yet surprisingly, implementing multi-factor authentication is not one of the top five priorities for technology investments this year. Only 16% are currently using some type of one time password with two-factor authentication and over 89% are just using user name and password to guard against inappropriate access to EHRs.

Source: Healthcare Information Security Today

The survey also shows 27% of organizations already offer a personal health record (PHR) portal and 35% have something in the works. The growth in adoption of consumer personal health record (PHR) portals really drives the need for why traditional authentication needs to make way for more dynamic and risk-based authentication.  The financial and online retail verticals have had to rely on such advanced authentication for multimillion user consumer bases.  The time has come for the healthcare industry to adopt these notions as well and deploy an adaptive intelligent framework which can morph as the threats do.  Transparent risk based authentication allows for instant, but secure, access to records in both patient and physician portals which is necessary to expedite emergency situations.  For example, if someone is accessing a patient record in an ER type of situation they need to quickly access data and do not want to be interrupted in their login workflow.  However, if someone is accessing clinical trial information remotely via a mobile device, you may want to require additional or stronger authentication requirements.  The level of authentication should be aligned to the level of risk. Integrating risk-based authentication with access management and identity federation helps organizations establish this balance because the data in a healthcare environment ranges in risk and value (e.g., credit card data for billing to PHI to appointment schedules) and multiple people across multiple functions and entitlements are accessing it.

Source: Healthcare Information Security Today

During a time of crisis organizations do not need to be more vulnerable to medical identity theft and fraud.  Advanced security solutions have provided the opportunity to help balance the risk, cost and convenience across all aspects of the healthcare ecosystem mitigating against threats while at the same time taking advantage of the benefits of easier information sharing.

Bottom line – this means improved patient care safety, streamlined business processes, physician productivity, cost efficiencies and most important – saved lives.

Angel Grant is a Senior Manager for RSA’s Authentication and Anti-Fraud solutions. She is responsible for a variety of initiatives which protect organizations against fraud and identity theft.  She has more than 20 years of experience in the security and financial services industries.

• 

…And they did it, they managed to slow down the internet. Next thing you know, they will break it! I am referring to what’s been called “the largest publicly announced online attack in the history of the Internet.”  And this week we read about the suspect; a 35-year old guy from Netherlands who was arrested in Spain (The Netherlands Public Prosecutor Service press release in Dutch).

This is interesting for two reasons:

1.) Supposedly, a single person can slow down the internet

2.) Flaws and more importantly the vulnerabilities of the Internet are being discussed in the main stream media.

Up until this news hit the media, the Internet was limitless in the public eye.  A big endless digital universe where there are billions of websites for everything and for everyone. The only Internet “speed” issues for the majority of public users were due to their own system performance or the connection – remember modem days anyone?

However, all of a sudden, there is news about a cyber attack actually slowing down the entire Internet. There were discussions about the specific details, the Geo-location effects, which users were impacted and how long, but regardless of the actual impact of this incident on Internet speed, the bigger impact might be how the perception of the Internet has changed; it doesn’t seem as limitless or abstract anymore.

Also interesting, this incident wasn’t “achieved” by an army of researchers and sophisticated coding, it was a DDoS attack by a single person and most likely due to a dispute between two companies. It got so much media attention that not only technology and security media, but global news organizations like the BBC  reported the incident.  Naturally, as it happens with most big news stories, discussions and disputes followed and the story lost its attraction for most audiences.

The real point is darker, though.  It’s about the vulnerabilities that cybercriminals and more specifically a single cyber criminal, have caused a public discussion about the Internet. Let’s hope that the change in public opinion will also help everyone realize that we exist in a physical world but live in a digital world that can be far more dangerous.  A world where our identities, reputations and finances are much more vulnerable.

As we continue to discuss the Cyber Intelligence Sharing and Protection Act (CISPA), its positives, negatives and impacts on privacy, we are already reading news stories on how DDoS attacks are increasing across industries.

Berk Veral is Senior Product Marketing Manager at RSA responsible for RSA FraudAction Anti-Phishing, Anti-Pharming, Anti-Trojan, and Anti Rogue App services as well as RSA FraudAction Intelligence and Cyber Crime Intelligence. Prior to joining RSA, Berk served as a senior member of product marketing teams at global technology companies where he worked closely with global financial institutions on technology solutions

• 

Typically when data is encrypted (AES, Triple DES, RSA, ECC, etc.), the encrypted data doesn’t look anything like the original. It is designed to be that way – because in most cases the output format of the data isn’t all that important. But, when you have systems have been built over long periods of time and need to talk to each other – the format of output becomes important.

FPE protects any kind of fixed-format data. Think credit cards, birth dates, social security numbers, account numbers… instead of turning it into a long blob, it keeps the format of the original data, making it easy for other systems or applications to use it. Very similar to tokenization, FPE-protected data looks like the original data BUT unlike tokenization, it uses a key.

This general goal of preserving some aspect of the original data is true of any FPE system. Most FPE systems give you the option to:

1. Preserve character set (Encrypt 10 numbers like SSNs, into 18 numbers)
2. Preserve length (Encrypt 16 numbers into 16 characters – binary okay, alpha okay)
3. Preserve some pieces (Encrypt 16 digit numbers into 18 digit numbers, but make sure the last 4 digits match)
4. Preserve all three; some pieces, character set, and length (Encrypt 16 digit card numbers into 16 digit numbers and keep the last 4 the same)

As with any technology, FPE has its advantages and disadvantages. FPE is a great approach for data that is resident for shorter periods of time in a transit system – think credit card processing, or claims processing in insurance. FPE is still encryption, so good key management is essential for a secure implementation. If format preservation over long periods of time is the use case, then Tokenization may be a better fit.

The consultant in me says, “it depends” (and the technical guy adds – “on the use case and data retention periods”). The good news is all of these options are available out of the box in RSA Data Protection Manager.

Vasu Nagendra

Sales Engineering Manager – Payment Security

As Sales Engineering Manager for RSA’s Payment Security Group, Vasu is responsible for strategic vision, solution architecture and customer integration for RSA’s encryption and tokenization solutions for global merchants and acquirers. He is an active participant in many industry standards committees related to encryption, key management, and tokenization. Vasu holds a MS degree in Electrical Engineering from Wright State University.

• 

Big Data is the buzzword making headlines today. From improving medical diagnosis and treatment to energy conservation, businesses around the world are using Big Data analytics to transform the data they store into actionable information.  Even here at RSA/EMC, we are working to leverage Big Data analytics to improve the way our customers detect and respond to threats.  You can be sure that if legitimate businesses are using the latest and greatest technology, cybercriminals are too!

Cybercriminals are also using Big Data principles to improve their own efficiency.  They have developed a variety of tools to better sort, analyze and monetize the volumes of data they collect.  For cybercriminals, the information collected in drop zones through Trojans on infected PCs (some of which have over a million infected PCs)  is clogging their infrastructure. As a result, malware authors have developed different parsing solutions and implemented the use of separate databases in their command & control administration panels in order to distill only the most pertinent data.

RSA has analyzed several tools that shed light on these developments, and demonstrate the ways in which cybercriminals are applying Big Data methodologies within their illicit operations.  Two examples of these tools include the “IntelegentBot” log-parser plugin and the Citadel Trojan’s “Money Panel” plugin.

The “IntelegentBot” log parser plugin, shown below, is designed to help a cybercriminal operating a botnet (botmaster) query their databases for valuable data.  This web-based platform allows botmasters to connect to their Trojan databases and search for specific words such as bank URLs or names.  It also allows botmasters to search for only credit card data.  Through the use of this plugin botmasters are able to quickly and easily mine and monetize credit card data, for example. Although some search options are part of basic botnet admin panels, this one is a commercial, standalone interface that can be adapted to different Trojans.

IntelegentBot Query Command Box Source: RSA AFCC

The “Money Panel” is designed to steal only credit card data and parse into a separate database.   This second plugin uses a special set of web injections specifically targeting credit card data, 16 numerical characters.  The web injection displays when a victim accesses a specific sites, such as a bank site or Facebook.  As soon as a victim enters their card information into the injected field, the data is collected, but instead of reaching the cluttered log repository, it is sent to a separate database in a remote server.

In addition to leveraging Big Data analytics to quickly sift through volumes of data, cybercriminals are using these tactics to derive intelligence from their collections of information to better understand trends and effectiveness of attacks.  This enables cybercriminals to make better decision for future attacks and investments as they learn more about infected machines, and the success of their existing malicious applications.  RSA analyzed the administrative functions and panels for the Citadel Trojan, image captured below.  The data-filtering and charting functionality show colorful statistics on firewall brands and anti-virus software installed on infected machines, providing botmasters with insight into the tools that could pose a problem to future activity.

Administrative Panel for Citadel Trojan Source: RSA AFCC

The sophistication, agility, and speed at which a cybercriminal operates and monetizes their fraudulent information have improved through the use of Big Data analytics.  Cybercriminals can now sort their collections of data more quickly to extract financial details and view performance metrics for current malware applications. This is certainly a trend to keep an eye on.  As cybercriminals continue to master the concepts of Big Data and apply it to their operations, their cyber-attacks stand to become more effective.  To combat these attacks, businesses will need to use intelligence-driven solutions that also leverage big data to deliver timely, actionable security decisions.

Kate McGavin is a Senior Product Marketing Manager at RSA, the Security Division of EMC, within the Identity and Data Protection group.  Kate supports the go-to-market and product launch efforts for the authentication offerings at RSA.  She is responsible for the development of strategic marketing plans through market research & business analysis, competitive analysis, and pricing model evaluation. Kate holds a BS in Marketing and Information Design Corporate Communication from Bentley University.

• 

Once again an attack against TLS has been published and again the attack targets cipher suites that use Cipher Block Chaining (CBC) mode encryption. This Man-in-the-Middle attack is easier to perpetrate than the previous Man-in-the-Browser attacks like “BEAST” and “CRIME,” but results in many failed TLS connections and requires statistical analysis of packet response times, which makes this plaintext recovery attack less practical.

This article will discuss the Lucky Thirteen attacks as applied to TLS and DTLS, the practicalities of the attack, and how to mitigate the attack.

Lucky Thirteen

Nadhelm Al Fardan and Kenny Paterson at Royal Holloway, University of London, developed the Lucky Thirteen attack. The name “Lucky Thirteen” was given to the attack because of how TLS performs the MAC calculation when authenticating packet data. The details of how the attack works are complicated and a summary follows.

A prerequisite for the attack is the ability to Man-in-the-Middle the connection between the client and server to read the clear text TLS handshake messages and inject modified ciphertext. This is most commonly achieved on an unsecured WiFi network.

By reading the handshake messages, the attacker knows that a vulnerable cipher suite was negotiated. Any cipher suite using CBC mode encryption, regardless of cipher or digest, is vulnerable. Cipher suites using SHA-1 are most easily attacked and were, until TLS v1.2, the most commonly used for reasons of security strength. The rest of the attack description assumes the use of SHA-1.

Once the attacker has established a vulnerable cipher suite is in use, they wait for application data to be sent. The client authenticates using HMAC-SHA1, and encrypts using a cipher in CBC mode. The data authenticated is:

|Sequence|Header|App Data|

|       8|     5|       n|

and the data encrypted is:

|Enc App Data|Enc MAC Tag|Enc Padding|

|           n|         20|          p|

Notice that the sequence and header in the authenticated data add up to 13 bytes. This is where the title of the paper comes from. The MAC tag is calculated using the sequence, header and application data: 13 + n. The CBC mode encryption is then performed on the application data, MAC tag and padding bytes: n + 20 + p.

Lucky Thirteen uses the same attack mechanism as the Padding Oracle Attack so this needs to be explained at this point.

Padding Oracle Attack

The Padding Oracle Attack was found to be applicable to implementations of SSL 3.0 and TLS 1.0. The SSL 3.0 and TLS 1.0 specifications state that if the decryption process fails due to a padding error, then an alert is sent. If the padding is correct then the MAC tag is checked. If the MAC tag is wrong then an alert is sent. Therefore the amount of work performed is dependent on whether the padding is correct. This means that alerts are sent at time differentials that can be distinguished.

CBC mode decryption takes the current encrypted block, decrypts it, and XORs in the previous ciphertext block. The Padding Oracle Attack uses this to determine the plaintext by modifying the previous ciphertext block. The first step in the attack is to truncate the message so that the plaintext to recover is the last block, where the padding is expected. Next the attack modifies the second last encrypted block. The last byte is XORed with a guess at the last plaintext byte. If the guess is correct, the last byte now decrypts to 0×00 – one byte of padding. Therefore, the decryption operation succeeds and the MAC operation is performed to check the authenticity of the data. The attacker detects that more time elapses before the alert is sent.

This attack was remediated by always performing the MAC. Most SSL 3.0 and TLS 1.0 implementations have this fix. TLS 1.1 specifications and beyond require the MAC operation be performed regardless of padding errors.

Back to Lucky Thirteen

Nadhelm and Kenny have found that always performing the MAC operation is not enough. The Lucky Thirteen attack assumes that the MAC is performed but finds differences in the amount of worked performed depending on the number of padding bytes.

In their example using TLS 1.1 and 1.2, the first application data packet is cut down to 85 bytes. The server interprets the packet as containing:

|Header|IV|Enc App Data|Enc MAC Tag|Enc Padding|

|     5|16|      44 – p|         20|          p|

Where p is the number of valid padding bytes. TLS requires the server decrypt:

|Enc App Data|Enc MAC Tag|Enc Padding|

|      44 – p|         20|          p|

Then, the authentication is performed on:

|Sequence|Header|App Data|

|       8|     5|  44 – p|

If no padding bytes are valid then p is 0 bytes and the application data is 44 bytes.

There are three scenarios to consider:

1. The padding is wrong and 57 bytes are MACed.
2. The last plaintext byte is 0×00 and 56 bytes are MACed.
3. The last two plaintext bytes are 0×01, 0×01 and 55 bytes are MACed.

The attack tries different values in the second last ciphertext block, this time in the last two bytes, in an attempt to force the last plaintext block to be the correct two bytes of padding. The attacker wants 55 bytes to be authenticated with HMAC-SHA1 because this can be distinguished computationally from 56 or 57 bytes. To understand why, an explanation of how SHA-1 processes its input data is required.

SHA-1

SHA-1 has an input block size of 64 bytes. That is, SHA-1 buffers up to 64 bytes before mixing the input with the internal state. But, the last thing SHA-1 and other hash functions do before generating the output is add padding of at least 1 byte and 8 bytes holding the length of the input data for a minimum of 9 extra bytes of input data. Therefore the last block of application data can be at most 55 bytes long.

And Back to Lucky Thirteen Again …

Therefore in scenarios 1 and 2 above, 66 (= 57 + 9) and 65 (= 56 + 9) bytes respectively, are mixed into the state which results in two blocks being processed. In Scenario 3, 64 (= 55 + 9) bytes are mixed into the state which results in one block being processed.

The thirteen is ‘lucky’ as only two bytes of padding need to be guessed: 55 authenticated bytes (13 header bytes + 42 application data bytes) and 64 decrypted bytes (42 application data bytes + 20 MAC tag + 2 padding bytes). As noted in the paper, 12 bytes would only require one byte of padding to be guessed and would have been ‘luckier’.

Practicalities of the Attack

In practice, to distinguish between the different scenarios requires measuring the difference between when the modified packet is sent and when the alert message is received. Looking for a difference of a thousand clock cycles, or 0.5 microseconds, when communicating across the Internet is a tall order.

Instead the authors found that each guess needed to be used multiple times – in fact, 128 times. By using basic statistical techniques the timing difference can be discerned. The experimental results used a single core server, but on a busy multi-processor server that uses a secure random (i.e. a noisy server system) it might not be as easy as described. If the TLS server is on an embedded system then the statistical analysis might prove more effective.

One important problem with the attack is that each attempt causes the TLS server to drop the connection. The packets being sent, even when the padding is correct, are not valid. If a client causes many failed connections on a continuous basis, hopefully the server will block them.

The attack can also be used on DTLS connections. DTLS is TLS over datagram protocols like UDP. UDP is unreliable. That is, the packets might not arrive, might come in out of order or might be corrupted. Therefore DTLS does not treat decryption and authentication errors as fatal and will keep accepting bad packets and reporting errors. DTLS is far more vulnerable to this attack than TLS.

Mitigation

The simplest way to protect against the “Lucky Thirteen” attack is to disable CBC cipher suites on the client and server. This leaves cipher suites that use RC4 and, if TLS 1.2 is available, AES-GCM.

Patches are being released that authenticate the same number of blocks regardless of padding. It is recommended that TLS servers be patched as soon as practically possible.

Summary

The “Lucky Thirteen” attack required the careful analysis of the TLS protocol and its use of cryptographic algorithms. It is not surprising that only now, many years after TLS 1.1 and 1.2 were released to fix the original Padding Oracle Attack, a new attack has been devised. The practicality of the attack is still in question when applied to heavily loaded TLS server machines, but DTLS and embedded TLS servers are easier targets.

While it is not clear that the attack is practical in all cases, it is clear that fixes need to be implemented to all TLS and DTLS servers.

Keep your servers secure by using secure cryptographic protocols.

Sean Parkinson is a Consultant Software Engineer at RSA based in Brisbane, Australia.

• 

I have mostly written about mobile apps; specifically on apps becoming an integral part of our daily lives. This is a fact that can be proven by the increase in the  number of apps available and downloaded via public app stores.

So what else is happening in the information security world? We are bombarded with news articles each day. The key is to identify the combined impacts of these seemingly disparate trends   ̶ or news and see the big picture and may be even predict the future.

The first story is seasonal news; more like an alert: the National Cyber-Forensics & Training Alliance (NCFTA) warns about tax refund scam as it is the tax season here in the US. Once again, fraudsters will try to convince people to click on their phishing emails that will appear to have come from the IRS or a legitimate financial institution to capture PII.

The second story is a recent Fortune article on why email spam is on the decline. According to the article, spammers are moving into new turf and using online advertising. This move is driven mainly by economics; placing online ads is cheaper than generating spam emails. The myriad of online ad options such as social media ads make it much less expensive to reach the masses.

The other interesting news comes from the SC Magazine with an article titled: “Fraud could rise if retail customers use Facebook login.” This one refers to a Gartner study which shows that half of new customers signing in to merchant websites will be using their social networking credentials. Consumers are demanding convenience of using social network credentials for online shopping, which in turn may expose online merchants to fraud if they have weak authentication methods.

As for the conclusion, if you still haven’t seen the connection, I will summarize it for you; fraudsters that use every opportunity to steal PII (such as the tax season), who also traditionally rely on spam emails are moving into more legitimate-looking online ads (such as social media ads), whereas consumers are moving in the direction of using a single online identity (their social media credentials) for most online activities (that include shopping): Stealthier fraud schemes plus convenience-seeking consumers is resulting in the need for new methods of information security around online identities, social media and fraud prevention. As I wrote above, when you connect separate news stories, you begin to see a different picture…..

Berk Veral is Senior Product Marketing Manager at RSA responsible for RSA FraudAction Anti-Phishing, Anti-Pharming, Anti-Trojan, and Anti Rogue App services as well as RSA FraudAction Intelligence and Cyber Crime Intelligence. Prior to joining RSA, Berk served as a senior member of product marketing teams at global technology companies where he worked closely with global financial institutions on technology solutions.

• 

I’m glad to see the 3DS (3D Secure) industry is finally catching up with RSA’s risk based strategy to address the consumer need for ease and convenience, while helping to protect customer PII as they shop on-line.   Because when it boils down to what cardholders want and what card issuers need; if it doesn’t work neither side will be willing to use it!

Case in point:  When you are shopping on-line and ready to check out, why don’t you have to input a username and password anymore… you know, the 3DS Verified by Visa, MasterCard SecureCode, or American Express SafeKey services?  The answer lies with how card issuers are now choosing to authenticate their cardholders.

Authentication is *still* happening, but it goes unnoticed by most users because the authentication is risk-based and only transactions that are considered high risk will require additional verification, something RSA calls “step-up authentication.”  By using a risk-based approach during the check-out process, cardholders have a more positive shopping experience that is undisturbed (in most cases) while their transactions are being protected (in the background) by their card issuing institution.  Card issuers which use RSA’s Adaptive Authentication for eCommerce have been mitigating card fraud like this for years.  That is why I like to call this a “win-win” situation.

RSA pioneered the use of risk-based authentication for 3DS card transactions since 2004, where only high risk transactions would require a cardholder to enroll with a username and password. In 2008, RSA worked closely with our partner customers to drive an even more positive user experience by using out-of-band authentication for transactions which are deemed high risk.  And in 2012, RSA helped protect over 475 million card transactions for our card issuing customers.    Long gone are the days of the cumbersome username and password, now RSA’s card issuing customers can choose to further authenticate their cardholders by having their customers: enter static card details, answer out of wallet questions, or be challenged with an SMS one-time password.

I cannot help but mention it is stamp of validation to learn within the 3DS industry, the use of risk-based authentication is now the preferred method of authentication.  And for that reason, I would like to say “Thank You.”

Rueben Rodriguez is a Principle Product Marketing Manager within RSA’s Identity and Data Protection Group.  He is responsible for the Adaptive Authentication for eCommerce solution which helps protect customers against fraudulent card activity in the on-line world.   Rueben has worked for 20 years within the financial services industry helping financial institutions process, administer, and protect payment information.  Rueben holds a B.S. from California State University Hayward.

• 

If the user passwords in your organization are compromised, do you:

a.)    Notify your users and ask them to change their passwords

b.)    Pro-actively reset all passwords immediately

As an end user, if your password is compromised, would you rather:

a.)    Be asked to reset the password yourself

b.)    Have the company reset your password for you

Last year, I received an e-mail from one of the social networking sites I frequent, in the wake of a bulk password theft, asking me to change my password.  I went ahead and did so, but I’m sure that many others did not.  And some that did change their passwords may not have done so immediately.  If, as an organization, you are concerned that attackers may use the credentials they have stolen to access user accounts, then time is of the essence.  So you’d want to reset all passwords now.

Over the weekend, Evernote took the proactive approach.  After discovering that attackers had managed to steal usernames, e-mail addresses and salted and hashed passwords, the company reset all 50 million of its users’ passwords.  Evernote notified their users via a blog post and via e-mail.  Based on the comments to Evernote’s blog post, reaction was mixed.  Users that suddenly found themselves unable to log in to their accounts (and hadn’t yet read the blog or received the e-mail) feared that their accounts had been hacked.  Some users that received the e-mail thought they were being targeted with phishing attacks (we’ve been well trained to be suspicious of e-mails about password resets).

If you are an organization dealing with a smash and grab attack on your stored passwords, the decision about whether to reset all user passwords can be another in a long line of stressful decisions.  When I talk to customers about RSA Distributed Credential Protection, one of the areas they get excited about is user transparency; in the event of such an attack, an organization can potentially change the way the password is split and stored without asking the end user to do anything.

From a security standpoint, I think Evernote did the right thing by resetting the passwords.  But it’s rough from a usability standpoint.  Users will have to log in and create a new password; they’ll also have to enter the new password on other Evernote apps.  If they were using the password elsewhere (most of us use the same password on over six unique portals or applications), they may want to think about changing their password on those portals as well.  But the password re-use issue is a subject for another day…

• 

I sometimes find myself making strange comparisons between real life and work life.  One of those stream-of-consciousness moments happened a few weeks ago while I was driving home in a snowstorm. 

I was minding my business driving along my normal route, but because of the road conditions, I was driving much slower than usual.  My mind started wandering – as it tends to do – and one of those strange comparisons came to mind:  Really, cybersecurity and driving aren’t all that different. To stay safe, both online and on the highway, we need to understand our surroundings and adapt accordingly to changing conditions. 

In the dynamic world in which we live, context is everything.  This holds true in the online world, too.  In our everyday lives, we constantly make decisions based on contextual data and potential consequences.  Why shouldn’t our security technologies make decisions in similar, intelligent ways?  

As attackers adapt their methods and continue to steal mass batches of login credentials, static usernames and passwords provide little assurance of the true identity of the user behind the password.  As a result, context-aware user authentication has become a necessary weapon in the battle to protect online identities.  To be effective in today’s world, our authentication methods must be able to understand the context of a login attempt, analyze that context to determine risk, and adapt requirements accordingly.  This is precisely the goal of risk-based authentication. 

By learning about a user’s online behavior over time, risk-based authentication technologies are able to establish a baseline of what is normal for any given user.  With that, it becomes easier to spot anomalous characteristics that often times indicate that there is an imposter, instead of the true user, behind the login credentials.  In high-risk scenarios, an effective solution should adapt to this atypical context by requiring stronger proof of identity – which an imposter will likely not be able to provide. 

By analyzing a variety of factors beyond just a simple username and password, context-aware risk-based authentication technologies can help organizations more effectively protect against fraudulent and unauthorized access attempts. 

With so much sensitive personal, financial, and company data available via the web, static approaches to identity protection just don’t cut it anymore.  Today’s world demands smarter, adaptable technologies.

 Just like new innovations, such as collision avoidance, help keep our bodies safe on the road, technologies such as risk-based authentication can help keep our identities safe online.

•