Cloud Encryption: It’s All About the Key Management

Cloud Encryption: It’s All About the Key Management

Garrett BekkerAugust 4, 2015

For security professionals, one of the primary challenges that arises with cloud computing is that they are faced with somehow protecting resources that, to varying degrees, they no longer have control over and for which traditional security controls like firewalls and IPS devices are ineffective.  However, regardless of which cloud model you adopt – IaaS, PaaS, SaaS, hosted private cloud, etc. – one thing you can still have some control over is your data.  But how to accomplish this when the data lives – at least part of the time – in someone else’s infrastructure?
As in other sectors of security, the emergence of cloud computing has breathed new life into certain long-existing security technologies, and in recent years, we’ve seen a ‘rebirth’ of encryption as a primary way to ensure that sensitive data remains protected even outside the corporate confines.  Encryption is arguably one of the oldest security tools and has been around for a millennia, but its complexity has often meant encryption has been relegated to the background and reserved for only the most stringent use cases.
Cloud has changed that.
As in the pre-cloud world, encryption does come with some potential drawbacks.  One of the main challenges is to implement encryption in a way that allows critical application features to still function normally, and also without impacting performance, uptime, and perhaps most importantly, the user experience.
The second major challenge, and arguably the more important one, is key management.  How you handle encryption keys, share them securely with others, rotate them, etc. is critical, since whoever controls the keys literally owns the data – history has given us plenty of examples of how either weak crypto or bad key management can be worse than having no encryption in the first place.
With respect to cloud security – and SaaS applications specifically – the issue of key management has been somewhat contentious.  A number of vendors have emerged in recent years that provide encryption for various SaaS applications using a gateway model that intercepts traffic en route to SaaS applications and encrypts sensitive data.  Most importantly, these vendors are able to do so in a way that most of the functionality of the SaaS app is preserved, and customers retain control of the keys on their own premises to ensure that nobody at the SaaS provider can access critical data – either maliciously, or perhaps in the event of a legal order.  The primary potential drawbacks to this approach are that it can be costly, both in terms of hardware and integration work, and application performance can be affected (particularly when applications are updated).
In addition to third-party encryption solutions, we’ve recently seen a move by both SaaS providers as well as big-data distributors to offer encryption and key management natively, so their customers can protect their data without the added cost and integration work that sometimes comes with third-party solutions.  Examples include big-data distributors Cloudera and Hortonworks, each of which acquired encryption vendors last year that allow them to offer encryption to their customers as either a standard feature or as a premium service.
Among SaaS providers, Box also offers its own native encryption, and earlier this year introduced a premium version that allows customers to maintain control over their encryption keys by physically separating them from Box’s internal servers and admins.  The most recent example is Salesforce’s launch of native encryption – called Platform Encryption – as part of its new Salesforce Shield premium security offering.  Platform Encryption has a variety of interesting features and has been architected in a way that makes it extremely difficult to be misused by Salesforce employees.  However, customers don’t have the option of keeping their encryption keys on their own premises, which may be OK with many customers, but not those facing strict compliance or data residency requirements.
The $64k question, then, is how many customers fall into each camp?  Cloud security is still at an early stage of development, and the market’s acceptance of Box’s EKM and Salesforce’s Platform Encryption should provide interesting test cases for how the cloud data-protection industry will unfold over time.  For the near-term, however, we think it’s likely that several models will co-exist, with both native and third-party offerings, as well as both provider-managed and customer-managed keys.  Either way, as cloud infrastructure and applications become more tightly woven into the fabric of most modern enterprises, encryption will increasingly be expected as a standard feature of most cloud offerings.  And as encryption assumes its rightful place in the cloud security toolkit, so too will the need for a key management system that supports a variety of cloud and encryption architectures and also scales to meet the demands of an elastic, on-demand infrastructure.  After all, whoever controls the keys, controls the kingdom.
Regardless of which camp you may fall in, historically, ‘good enough security’ has been, well – good enough.  Too many organizations have been content to check off compliance boxes and move on.  However, we are seeing increasing evidence that this may be changing, and the seemingly endless parade of data breaches may be causing more companies to think about implementing security best practices rather than just doing the bare minimum.   That said, our guess is that for the time being, the lack of an on-prem key management option is not a deal killer for the majority of customers.
For large SaaS, IaaS and big-data providers, we are likely to see more native encryption options come to market as they look to meet customer demands for data protection. But how will they handle key management?  Will they follow Salesforce’s lead and keep the keys to themselves, or adopt Box’s model and let customers keep control?
As mentioned earlier, for customers with strict internal security policies or those facing data residency requirements, on-prem key management will remain a must, and for this group, third-party encryption vendors will still play a large role.  Either way, we see third-party vendors evolving more towards key management and away from basic encryption, particularly as more customers adopt multiple cloud applications and may have a need for a centralized way of managing their keys.
For smaller SaaS providers, many may opt to integrate third-party encryption and key management offerings directly into their products rather than expending the time and resources that Salesforce and Box likely did to develop with their own native offerings.
Regardless of how things play out, key management will remain a central issue in the battle for cloud data security.
Larger SaaS, IaaS and big-data providers are likely to deliver more native encryption options as they look to meet customer demands for data protection, and many will opt to architect their offerings with an on-premise key management option.  Smaller SaaS providers with less internal resources and expertise may opt to integrate third-party encryption and key management offerings directly into their products.

Garrett Bekker is a Senior Analyst in the Enterprise Security Practice at 451 Research, drawing on more than 15 years of enterprise security experience. For more security insights from Garrett, follow him on Twitter via @gabekker and read his 451 Research reports.

- See more at: http://data-protection.safenet-inc.com/2015/08/cloud-encryption-its-all-about-the-key-management/#sthash.MzShzomz.5xwzQfow.dpuf

Target to pay up to $67m in data breach settlement with Visa

By Sooraj Shah       

21 Aug 2015         

US retailer Target could pay up to $67m to Visa and banks that issue Visa cards for the costs incurred as a result of the devastating hack in which the payment card details of 40 million customers were stolen.
The attack, which occurred in 2013, saw approximately 110 million Target customers' personal data being stolen, and the company has since faced legal action from consumer groups and financial institutions over the breach.

           

However, any bank that agrees to this settlement deal will have to drop their involvement in any other legal action, according to Reuters. Many Visa card-issuing banks support the legal action brought forward by Visa, according to The Wall Street Journal.
Target is now working on a similar deal with MasterCard, after an initial $19m settlement was not supported by a sufficient number of MasterCard-issuing banks.
The US retailer's card details were stolen after the attackers, using compromised network-access credentials stolen from one of the company's suppliers, were able to plant malware onto Target's security and payments system. This enabled them to cream off the credit card details from every transaction at the company's 1,797 US stores.
While the attack was spotted almost straightaway by FireEye, the company's security monitoring company, and by its own IT security staff in Bangalore, staff at the company's headquarters completely failed to heed their warnings. Target head office staff only responded when the US Department of Justice notified the retailer of the breach in mid-December 2013.
Had Target acted on the initial warnings, the attack would have been prevented.
As a result of the hack, Target's CEO Gregg Steinhafel and its CIO Beth Jacob resigned from their roles. The firm hired Bob DeRodes in a fire-fighting CIO role in the aftermath of the hack, but he has since retired and been replaced by former Tesco CIO Mike McNamara.

Walmart FCPA spending just topped $650 million

Walmart FCPA spending just topped $650 million

By Richard L. Cassin | Wednesday, August 19, 2015 at 10:08AM

Walmart said in a management call Tuesday that FCPA and compliance-related costs were about $30 million during the second quarter, with $23 million for ongoing investigations and $7 million for the company's global compliance program.
The company said it expects to spend between $130 million and $150 million on FCPA-related costs for the full year.
First quarter FCPA and compliance-related costs this year were $33 million.
In April 2012, the New York Times reported that Walmart's Mexico unit paid $24 million in bribes to speed up licensing and permitting for new stores. The paper said top managers in the United States covered up the bribery after learning about it.
The DOJ and SEC are investigating possible FCPA violations in Mexico, as well as in China, India, and Brazil, among others.
The Bentonville, Arkansas-based retailer said for fiscal 2015 (ended January 31), FCPA-related costs were $173 million.
In its fiscal 2014 Global Compliance Program Report, Walmart said it had spent $439 million in legal fees and other costs associated with investigations of alleged FCPA violations, and to revamp its global compliance program.
FCPA costs were $282 million in 2014 and $157 million in 2013, the company said.

- See more at: http://www.fcpablog.com/blog/2015/8/19/walmart-fcpa-spending-just-topped-650-million.html#sthash.aR2aZCl3.dpuf

IRS: Hack Much Wider Than First Thought

IRS: Hack Much Wider Than First ThoughtIntruders Might Have Stolen PII from 334,000 Accounts


Eric Chabrow (GovInfoSecurity) • August 17, 2015  

The Internal Revenue Service says cyber thieves may have accessed as many as 334,000 taxpayer accounts in a breach of its Get Transcript system, far more than the 114,000 accounts it originally estimated in May (see IRS: 100,000 Taxpayer Accounts Breached).
See Also: Mobile Banking: Empowering Banks to Protect Customers Against Online Fraud
The Get Transcript online service, suspended in May, is aimed at simplifying the process taxpayers use to retrieve their tax records. It enables taxpayers to review their tax account transactions, line-by-line tax return information or wage and income reported to the IRS for a specific tax year. By circumventing Get Transcript's authentication protections, hackers are believed to have gained access to this taxpayer information, including Social Security numbers.
Since its initial investigation, the IRS has conducted a more extensive review, analyzing more than 23 million uses of the system, covering the 2015 filing season, to determine whether other suspicious activities occurred and identify "more questionable attempts" to obtain taxpayer records through the Web application, according to an Aug. 17 agency statement.
The latest review identified an additional 220,000 suspicious records access attempts that cleared the Get Transcript verification process. That review also identified another 170,000 suspicious attempts that failed to clear the automated authentication process.

Challenges in Indentifying Scope

"When a breach of a system like this occurs, it is always a challenge to identify the scope," says Ken Westin, senior security analyst for the IT security firm Tripwire. "The entire database itself was not compromised directly. Instead, the data was harvested from legitimate website forms, making it more difficult to identify which requests were fraudulent and which were legitimate."
The IRS didn't furnish details on how it uncovered the additional taxpayer accounts that were potentially breached. But skilled hackers might have made it more difficult for the tax agency to quickly assess the complete impact of the breach, says a top congressional information security investigator, who has no direct knowledge of the IRS probe.
"One of things that makes it difficult, particularly if the attacker or intruder is sophisticated, is their ability to eliminate and delete evidence of their actions," says Gregory Wilshusen, information security issues director at the Government Accountability Office, the investigative arm of Congress. "That may make it difficult for the agency to track with certainty the extent to which either files have been exfiltrated or corrupted or accessed. In part, it depends upon the skill and ability of the intruder to mask their actions."
In May, according to the IRS, the agency determined unauthorized third parties previously gained sufficient information from a source outside the tax agency before accessing the Get Transcript Web application that enabled the hackers to clear a multi-step authentication process. The process includes answering several personal verification questions.
At the time, the IRS estimated that the hackers might have gained access to 114,000 taxpayer accounts. Attempts to access another 110,000 accounts failed because the hackers could not properly answer the verification questions, according to the IRS' original estimate.

Knowledge-Based Authentication

The method the Internal Revenue Service used to authenticate users for accessing the Get Transcript application - known as knowledge-based authentication, or KBA - has been widely panned by cybersecurity experts (see IRS Authentication Method Criticized). The dynamic version of KBA used by the IRS poses personal knowledge questions for users to answer in order to verify their identity, such as the maiden name of the taxpayer's mother. The answers to the questions are based on public and private information the IRS gathers, such as marketing data, credit reports and transaction history.
"Knowledge-based authentication is a tired technology that has been compromised with the ubiquity of personal information available in social media," says Robert Siciliano, online safety expert with Intel Security. "Any entity that's solely relying on knowledge-based authentication is in the dark ages."

Notices Going Out

In the coming days, the IRS says it will mail letters to the taxpayers whose accounts might have been inappropriately accessed. "Given the uncertainty in many of these cases - where a tax return was filed before the Get Transcript access occurred for example - the IRS notices will advise taxpayers that they can disregard the letter if they were actually the ones seeking a copy of their tax return information," the IRS statement says.
As an additional protective step, the IRS says it also will mail letters alerting other taxpayers that although identity thieves failed in efforts to access their records via the Get Transcript system, their information still might be at risk.
The tax agency cautions that some of the pilfered information might be used by fraudsters to file fake tax returns in 2016, and advises taxpayers to take steps to protect themselves through free credit monitoring the IRS is offering to those whose information is believed to have been inappropriately accessed. The IRS is also issuing personal identity numbers to those potentially affected by the breach that can be used to verify the authenticity of next year's tax return.
The IRS says it continues work to strengthen the Get Transcript system before it will be reactivated; it didn't provide a date when it would be resuscitated.

IRS breach may exceed 300K victims

 

IRS breach may exceed 300K victims

The Internal Revenue Service (IRS) breach that took place in May could now affect more than 300,000 taxpayer accounts, the agency said in a statement Monday.
The IRS said a deeper look at the breach indicated that hackers may have gained access to an additional 220,000 taxpayer files. "The IRS has identified more questionable attempts to obtain transcripts using sensitive information already in the hands of criminals," the statement said.
The agency said it start mailing notification letters "to about 220,000 taxpayers where there were instances of possible or potential access to 'Get Transcript' taxpayer account information" and, in an abundance of caution, to about 170,000 other households saying their data "could be at risk even though identity thieves failed in efforts to access the IRS system."
The IRS reported in May that about 114,000 files were compromised when hackers used social security numbers and other personal information to access old tax returns through the tax agency's Get Transcript system.

Classificatie, effe snel doen?

Classificatie, effe snel doen?

NIST releases SHA-3 cryptographic hash standard

NIST releases SHA-3 cryptographic hash standard

Posted on 06 August 2015.

The National Institute of Standards and Technology (NIST) has released the final version of its "Secure Hash Algorithm-3" standard, a next-generation tool for securing the integrity of electronic information.

Nine years in the making, SHA-3 is the first cryptographic hash algorithm NIST has developed using a public competition and vetting process that drew 64 submissions worldwide of proposed hashing algorithms. The new standard— Federal Information Processing Standard (FIPS) 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions—is available for download from NIST's website.

Hash algorithms are broadly useful in the world of electronic communications. They transform a digital message into a short "message digest" for use in digital signatures and other applications. Even a small change in the original message creates a change in the digest, making it easier to detect accidental or intentional changes to the original message. Hash functions can be used in a variety of security applications such as message authentication. They also are useful during routine software upgrades to make sure that the new software has not been tampered with.

The SHA-3 standard does not differ markedly from the draft version that was released for public comment in May 2014. It specifies a family of functions based on Keccak, the winning algorithm selected from NIST's SHA-3 Cryptographic Hash Algorithm Competition.

SHA-3 is not the only family of hash functions that NIST approves for hashing electronic messages; the SHA-2 family, specified in FIPS 180-4 that NIST approved for use in 2002, remains secure and viable.

"SHA-3 is very different from SHA-2 in design," says NIST's Shu-jen Chang. "It doesn't replace SHA-2, which has not shown any problem, but offers a backup. It takes years to develop a new standard, and we wanted to be prepared in case problems do occur."

According to Chang, the two standards will complement each other and offer more options to designers of both hardware and software. Some of the SHA-3 functions can, for example, be implemented without requiring much additional circuitry on a chip, potentially making them useful alternatives for securing very small devices.