uncompiled.com

Trend Micro is blazing a new trail with a service called SecureCloud intended to give enterprises a way to encrypt data in cloud-computing environments.

SecureCloud allows you to maintain control over the encryption key used to secure data stored in the Amazon EC2, Eucalyptus or VMware vCloud cloud infrastructures. Other cloud-computing variants could be added in the future.

“IT operations may be firing up [a remote virtual machine] image but we have security validating the integrity, and it’s encrypted until it hits the cloud, and it’s encrypting data at rest,” according to Todd Thiemann, senior director of data center security and marketing at Trend Micro.

He notes that SecureCloud allows the IT department using either public or private cloud-computing services to answer the basic questions, “Is this image OK? And is it mine?”

Now in beta with general availability expected by year end, SecureCloud is provided through a Web site portal and makes use of policy-based encryption to allow access to a virtual-machine image as well as storing related activity logs.

In addition to offering the security service, Trend Micro is looking at making comparable software available to companies for on-premises use.

In a separate announcement, Trend Micro also unveiled an antimalware protection module for its VMware server security software, Deep Security 7.5. It includes integrity monitoring, log inspection and stateful firewall capabilities, and leverages the most recent VMware vShield Endpoint APIs. Trend Micro Deep Security 7.5 is expected to ship in October.

Source

A top British codebreaker found mysteriously dead last week in his flat had worked with the NSA and British intelligence to intercept e-mail messages that helped convict would-be bombers in the UK, according to a news report.

Gareth Williams, 31, made repeated visits to the U.S. to meet with the National Security Agency and worked closely with British and U.S. spy agencies to intercept and examine communications that passed between an al Qaeda official in Pakistan and three men who were convicted last year of plotting to bomb transcontinental flights, according to the British paper the Mirror.

Williams, described by those who knew him as a “math genius,” worked for the Government Communications Headquarters (GCHQ) helping to break coded Taliban communications, among other things. He was just completing a year-long stint with MI6, Britain’s secret intelligence service, when his body was found stuffed into a duffel bag in his bathtub. He’d been dead for at least two weeks. His mobile phone and a number of SIM cards were laid out on a table near the body, according to news reports. There were no signs of forced entry to the apartment and no signs of a struggle.

Initial news stories indicated Williams had been stabbed, but police have since disputed that information, noting that — other than being stuffed into a duffel bag — there were no obvious signs of foul play. A toxicology report is expected Tuesday.

Investigators say they haven’t ruled out the possibility that the codebreaker was killed over something related to his work. Rumors that sexual bondage equipment was found in his apartment were also nixed by police, who said the rumors were untrue and they found no evidence yet to suggest that anything in Williams’ personal life led to his death.

Williams, an avid cyclist, lived in an apartment in Pimlico in central London that was reportedly part of a network of flats registered to an offshore front company and rented out to GCHQ workers. He is believed to have returned from a trip abroad on August 11. He was last seen alive on August 15, eight days before his body was found.

Williams flew up to four times a year to the U.S. to the NSA’s headquarters at Fort Meade HQ, according to the Mirror. His uncle, Michael Hughes, told the paper that Williams would mysteriously disappear for three or four weeks.

“The trips were very hush-hush,” Hughes said. “They were so secret that I only recently found out about them – and we’re a very close family. It had become part of his job in the past few years. His last trip out there was a few weeks ago, but he was regularly back and forth.”

Williams was said to have worked with the NSA on e-mails intercepted between Abdullah Ahmed Ali and Assad Sarwar and Rashid Rauf, a British national in Pakistan who was allegedly director of European operations for al Qaeda. The e-mails, intercepted by the NSA in 2006, allegedly contained coded messages.

The NSA shared the e-mails with British prosecutors but wouldn’t allow them to use the evidence in an early trial of the suspects out of fear of tipping off Rauf that he was under surveillance. It was only after Rauf was reportedly killed in a U.S. drone attack that the NSA allowed prosecutors to use the e-mails to convict the other suspects. It’s never been known whether the NSA intercepted the messages overseas or siphoned them as they passed through internet nodes on U.S. soil as part of the NSA’s controversial and unconstitutional warrantless wiretapping program.

An unidentified Western intelligence source told the Mirror that Williams’ job would have had him participating in “crucial high-level meetings with American intelligence officers. His job would have been crucial to the security of the UK and our interests abroad – and also to America and Europe.

“Although not particularly high up the GCHQ ladder, the importance of his role should not be underestimated. The man was a mathematical genius.”

His landlady, Jenny Elliott, told the Telegraph, “Occasionally you could hear tapes whirring from his flat, which must have been audio cassettes he used for work, but he never told me what they were.”

Source

There’s a tremendous buzz today about cloud computing, but before outsourcing your critical business systems to the cloud let’s review some security concerns.

The most critical business applications deal with corporate HR, finance, credit card, and other sensitive data. If any of this information is compromised lawsuits may ensue and your corporate brand is tarnished. This is a nightmare that could lead to customers avoiding purchasing your products or services. How can cloud computing effectively protect sensitive data?

There are three areas that need to be addressed to effectively push your applications into the cloud:

Let’s start with defense in depth.

First, put sensitive data in a second tier of firewall segments behind the main corporate firewalls. This second-tier firewall and corresponding network shields sensitive applications and their data from being easily accessed if the Web-facing firewalls are breached. For example, let’s look at grocery stores. It would be wise to deploy at least four firewall/network segments: one for HR data, one for financial data, one for credit card PCI (Payment Card Industry) data, and one for services that the other segments share. The segment containing services that are shared could contain common support services such as network and systems management, encryption and PKI functions, access control services, and security event management functions.

Another architectural implementation that protects corporations from internal data theft is the creation of a Tunneling Access Protocol. The Tunnel Access Protocol is an access control function that forces all administrators to log information before they perform administration on segment systems. Hence, all administrative access is tracked, discouraging internal theft of information

The second area that needs addressing is the analysis needed to determine successful migration of the application to behind the cloud’s second-tier firewalls. I recommend starting with the application design document first. It gives you a big-picture understanding of which business need the application performs, what middleware is used, what databases are used, and what protocols it uses. It also often contains the logical architecture.

It is important to focus on all the systems the application interacts with. Your security team will have a variety of information collected about the application: what data is sensitive, how and what tools are used to encrypt the data, and penetration testing results if it is a Web-facing application. Also, I recommend creating a protocol diagram showing all servers and their IP addresses, the protocols being used, and the protocol (TCP or UDP) ports being used. This network view specifically shows which servers need to talk to each other and what protocols (ports) they will use to do it. It is not necessary to include switches, routers and other network infrastructure components because the protocols/ports just ride over them. If the protocol diagram is thorough, it should be a simple step to create the firewall rules. Firewall rules are made up of source and destination IP (Internet Protocol) addresses, protocol used, and ports that ride on top of those protocols.

Lastly, I recommend a thorough collection of system and application metadata. The need to port your application well requires this work. Plus, if you have a disaster, business interruption or want to pull your application from the cloud — you need this data. System information exists per firewall/network segment. All applications share the same system data such as the same firewall, routers, switches, encryption algorithm (if used for all applications in a segment), and storage subsystem. System metadata includes vendor, model, software release and version, and other system-wide configuration data. Application data is similar but it addresses load balancers, encryption method, middleware, database, server hardware and operating system, and services, protocols, and ports that ride on top of those systems. Application metadata includes vendor, model, software release and version, and other application configuration data.

The next debate is where this metadata should be contained. I recommend containing this information in a hierarchy in a LDAP repository. I would create two tiers in the directory: one called Segment System for each of the four segments in the example above, and lastly one called Application for all applications within a given segment. This ordering enables a systematic collection of all metadata so that sensitive cloud applications can quickly be deployed. And, most importantly, it enables a quick deployment of the application and/or segment into a cloud.

In summary, migrating critical cloud applications involves putting data behind a second tier of firewalls. Common services exist in one of the segments that can be shared by all segmented applications. Applications should be in separate segments based upon the type of data that is being protected such as credit card data, finance data and HR data, and services that are shared. A variety of documentation should be created and/or reviewed to make sure that the porting of applications behind the second-tier ‘deep theater’ defense firewalls goes well. This collected metadata is from a hierarchy of two layers: common system per segment and different applications within each segment. I recommend the metadata be saved in a directory where it can be easily retrieved.

Source

OpenSSH 5.6 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0
implementation and includes sftp client and server support.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:

http://www.openssh.com/donations.html

Changes since OpenSSH 5.5
=========================

Features:

* Added a ControlPersist option to ssh_config(5) that automatically
starts a background ssh(1) multiplex master when connecting. This
connection can stay alive indefinitely, or can be set to
automatically close after a user-specified duration of inactivity.

* Hostbased authentication may now use certificate host keys. CA keys
must be specified in a known_hosts file using the @cert-authority
marker as described in sshd(8).

* ssh-keygen(1) now supports signing certificate using a CA key that
has been stored in a PKCS#11 token.

* ssh(1) will now log the hostname and address that we connected to at
LogLevel=verbose after authentication is successful to mitigate
“phishing” attacks by servers with trusted keys that accept
authentication silently and automatically before presenting fake
password/passphrase prompts.

Note that, for such an attack to be successful, the user must have
disabled StrictHostKeyChecking (enabled by default) or an attacker
must have access to a trusted host key for the destination server.

* Expand %h to the hostname in ssh_config Hostname options. While this
sounds useless, it is actually handy for working with unqualified
hostnames:

Host *.*
Hostname %h
Host *
Hostname %h.example.org

* Allow ssh-keygen(1) to import (-i) and export (-e) of PEM and PKCS#8
keys in addition to RFC4716 (SSH.COM) encodings via a new -m option
(bz#1749)

* sshd(8) will now queue debug messages for bad ownership or
permissions on the user’s keyfiles encountered during authentication
and will send them after authentication has successfully completed.
These messages may be viewed in ssh(1) at LogLevel=debug or higher.

* ssh(1) connection multiplexing now supports remote forwarding with
dynamic port allocation and can report the allocated port back to
the user:

LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`

* sshd(8) now supports indirection in matching of principal names
listed in certificates. By default, if a certificate has an
embedded principals list then the username on the server must match
one of the names in the list for it to be accepted for
authentication.

sshd(8) now has a new AuthorizedPrincipalsFile option to specify a
file containing a list of names that may be accepted in place of the
username when authorizing a certificate trusted via the
sshd_config(5) TrustedCAKeys option. Similarly, authentication
using a CA trusted in ~/.ssh/authorized_keys now accepts a
principals=”name1[,name2,...]” to specify a list of permitted names.

If either option is absent, the current behaviour of requiring the
username to appear in principals continues to apply. These options
are useful for role accounts, disjoint account namespaces and
“user@realm”-style naming policies in certificates.

* Additional sshd_config(5) options are now valid inside Match blocks:

AuthorizedKeysFile
AuthorizedPrincipalsFile
HostbasedUsesNameFromPacketOnly
PermitTunnel

* Revised the format of certificate keys. The new format, identified as
ssh-{dss,rsa}-cert-v01@openssh.com includes the following changes:

– Adding a serial number field. This may be specified by the CA at
the time of certificate signing.

– Moving the nonce field to the beginning of the certificate where
it can better protect against chosen-prefix attacks on the
signature hash (currently infeasible against the SHA1 hash used)

– Renaming the “constraints” field to “critical options”

– Addng a new non-critical “extensions” field. The “permit-*”
options are now extensions, rather than critical options to
permit non-OpenSSH implementation of this key format to degrade
gracefully when encountering keys with options they do not
recognize.

The older format is still supported for authentication and may still
be used when signing certificates (use “ssh-keygen -t v00 …”).
The v00 format, introduced in OpenSSH 5.4, will be supported for at
least one year from this release, after which it will be deprecated
and removed.

BugFixes:

* The PKCS#11 code now retries a lookup for a private key if there is
no matching key with CKA_SIGN attribute enabled; this fixes fixes
MuscleCard support (bz#1736)

* Unbreak strdelim() skipping past quoted strings (bz#1757). For
example, the following directive was not parsed correctly:

AllowUsers “blah blah” blah

* sftp(1): fix swapped args in upload_dir_internal(), breaking
recursive upload depth checks and causing verbose printing of
transfers to always be turned on (bz#1797)

* Fix a longstanding problem where if you suspend scp(1) at the
password/passphrase prompt the terminal mode is not restored.

* Fix a PKCS#11 crash on some smartcards by validating the length
returned for C_GetAttributValue (bz#1773)

* sftp(1): fix ls in working directories that contain globbing
characters in their pathnames (bz#1655)

* Print warning for missing home directory when ChrootDirectory=none
(bz#1564)

* sftp(1): fix a memory leak in do_realpath() error path (bz#1771)

* ssk-keygen(1): Standardise error messages when attempting to open
private key files to include “progname: filename: error reason”
(bz#1783)

* Replace verbose and overflow-prone Linebuf code with
read_keyfile_line() (bz#1565)

* Include the user name on “subsystem request for …” log messages

* ssh(1) and sshd(8): remove hardcoded limit of 100 permitopen clauses
and port forwards per direction (bz#1327)

* sshd(8): ignore stderr output from subsystems to avoid hangs if a
subsystem or shell initialisation writes to stderr (bz#1750)

* Skip the initial check for access with an empty password when
PermitEmptyPasswords=no (bz#1638)

* sshd(8): fix logspam when key options (from=”…” especially) deny
non-matching keys (bz#1765)

* ssh-keygen(1): display a more helpful error message when $HOME is
inaccessible while trying to create .ssh directory (bz#1740)

* ssh(1): fix hang when terminating a mux slave using ~. (bz#1758)

* ssh-keygen(1): refuse to generate keys longer than
OPENSSL_[RD]SA_MAX_MODULUS_BITS, since we would refuse to use
them anyway (bz#1516)

* Suppress spurious tty warning when using -O and stdin is not a tty
(bz#1746)

* Kill channel when pty allocation requests fail. Fixed stuck client
if the server refuses pty allocation (bz#1698)

Portable OpenSSH Bugfixes:

* sshd(8): increase the maximum username length for login recording
to 512 characters (bz#1579)

* Initialize the values to be returned from PAM to sane values in
case the PAM method doesn’t write to them. (bz#1795)

* Let configure find OpenSSL libraries in a lib64 subdirectory.
(bz#1756)

Checksums:
==========

– SHA1 (openssh-5.6.tar.gz) = fa5ac394b874d6709031306b6ac5c48399697f7f
– SHA1 (openssh-5.6p1.tar.gz) = 347dd39c91c3529f41dae63714d452fb95efea1e

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
Security bugs should be reported directly to openssh@openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.

Source

Developers of the 14 semifinalist algorithms for the new SHA-3 Secure Hash Algorithm standard will have a chance to defend their work next week at the second NIST candidate conference, being held at the University of California, Santa Barbara.

“We’re creating a record” on which to base selection of four to six finalists, expected to be named by the end of the year, said Bill Burr, manager of the Cryptographic Technology Group a the National Institute of Standards and Technology. “All in all we’ve got quite a bit of performance data. At this point we have a surprising amount of data on hardware implementation on all 14 candidates.”

Final selection of a new standard hashing algorithm for government is expected by early 2012, although that date could slip if additional analysis is needed, Burr said.

A hashing algorithm is a cryptographic formula for generating a unique, fixed-length numerical digest—or hash—of a message. Because the contents of the message cannot be derived from the hash and because the hash is to a high degree of probability unique for each message, it can be used to securely confirm that a document has not been altered. It also can be used to effectively sign an electronic document and link the signature to the contents.

SHA-3 will augment and eventually replace those algorithms now specified in Federal Information Processing Standard 180-2. The standard now includes SHA-1 as well as SHA-224, SHA-256, SHA-384 and SHA-512, collectively known as SHA-2. The standards undergo regular reviews and the decision was made to open a competition for SHA-3 in 2007 after weaknesses had been discovered in the currently approved algorithms.

Sixty-four algorithms were submitted to NIST in 2008, of which 51 were met minimum criteria for acceptance in the competition. The cryptographic community spent the next year hammering at the candidates, looking for flaws and weaknesses and 14 algorithms advanced to the second round in July 2009. The 14 second-round candidates are BLAKE, Blue Midnight Wish, CubeHash, ECHO, Fugue, Grøstl, Hamsi, JH, Keccak, Luffa, Shabal, SHAvite-3, SIMD and Skein. Candidate algorithms are available online, and NIST has published a status report on the first round of the competition.

Next week’s conference will give the entrants a chance to address the results of analysis and testing over the past year. The conference is being held in conjunction with this week’s overlapping CRYPTO 2010 conference and the workshops on Cryptographic Hardware and Embedded Systems, being held by the International Association for Cryptologic Research at Santa Barbara.

Harnessing the collective brainpower of the cryptographic community to identify strengths and weaknesses of possible hash algorithms is the idea behind the competition. This is the third cryptographic competition conducted by NIST to select a standard algorithm. The first, to select the Digital Encryption Standard in the 1970s, drew just two submissions, only one of which was seriously considered. In the 1990s the competition for the DES replacement, the Advanced Encryption Standard, drew about 15 submissions.

With 14 semifinalists to hear from, the conference schedule will be tight, with each presenter having only about 15 minutes to address results of analysis over the past year and present an argument for moving to the final round. After a second year of testing and analysis by the crypto community, a final candidate conference is expected to be held in the winter of 2012.

Even when the field has been narrowed to about five finalists, doing an analysis of cryptographic tools that are expected to remain in the federal toolkit for years to come takes considerable time and effort, Burr said, and there have been calls to slow down the process and extend it beyond the current 2012 end point.

“I’m not inclined to do that, but I’m open to arguments,” Burr said.

The timeline for selection will depend in part on developments in cryptography and in attacks against existing standards, he said. NIST might have some additional breathing space in selecting a new standard algorithm because there has been little progress toward breaking SHA-2.

“There was a lot of fear about how much progress there would be in attacking SHA-2,” Burr said, but hackers to not appear to be focusing on that. “SHA-2 is falling, although more slowly than we thought.”

Source

Security expert Georgi Guninski has pointed out a security issue in the 1.0 branch of OpenSSL that potentially allows SSL servers to compromise clients. Apparently the hole can be exploited simply by sending a specially crafted certificate to the client, causing deallocated memory to be accessed in the ssl3_get_key_exchange function (in ssl\s3_clnt.c). While this usually only causes an application to crash, it can potentially also be exploited to execute injected code.

Guninski included a certificate and a flawed key for recreating the problem in the report he released on the Full Disclosure mailing list. When tested briefly by the The H’s associates at heise Security on an current Ubuntu 10.04 system with OpenSSL 0.9.8k, a certificate belonging to an RSA key of only 4006 bits in length (and where q is not prime) only produced a warning that the certificate was flawed.

As virtually none of the Linux distributions use OpenSSL 1.0.x, the hole is unlikely to create major concerns. An update has yet to be released by the OpenSSL developers, but the issue is already being discussed on the OpenSSL developer mailing list.

Source

You may have heard the rumor that swirled briefly last month about an Internet “kill switch” that could power down the Web in the case of a critical cyber attack. Those rumors turned out to be largely overblown, but it turns out there are now seven individuals out there holding keys to the Internet. In the aftermath of a cataclysmic cyber attack, these members of a “chain of trust” will be responsible for rebooting the Web.

The seven members of this holy order of cyber security hail from around the world and recently received their keys while locked deep in a U.S. bunker. But the team isn’t military in nature. The Internet safety program is overseen by the Internet Corporation for Assigned Names and Numbers (ICANN), a non-profit watchdog group that has access to a security system designed to protect users from cyber fraud and cyber attacks.

Part of ICANN’s security scheme is the Domain Name System Security, a security protocol that ensures Web sites are registered and “signed” (this is the security measure built into the Web that ensures when you go to a URL you arrive at a real site and not an identical pirate site).

Most major servers are a part of DNSSEC, as it’s known, and during a major international attack, the system might sever connections between important servers to contain the damage.

A minimum of five of the seven keyholders – one each from Britain, the U.S., Burkina Faso, Trinidad and Tobago, Canada, China, and the Czech Republic – would have to converge at a U.S. base with their keys to restart the system and connect eveything once again. We’re imagining a large medieval chamber filled with techno-religious imagery where these knights cyber must simultaneously turn hybrid thumb drive/skeleton keys in a massive router, filling the room with the blinking light of connectivity.

In reality, it’s not so dramatic. The keys are actually smartcards that each contain parts of the DNSSEC root key, which could be thought of as the master key to the whole scheme. But it is interesting to know that there is a group of individuals out there that hold actual, physical keys that would reboot the Internet as we know it.

Source

LAS VEGAS–A security researcher has found a slew of fundamental problems with the way that modern browsers are designed and built, leading to serious questions about the security of these applications and the way that they handle SSL sessions.

The research, done by Robert Hansen of SecTheory, shows that browsers such as Firefox, Internet Explorer and Chrome have a number of architectural problems that can essentially negate the security that SSL is meant to provide for sensitive Web transactions. The techniques that Hansen has developed, which he demonstrated at the Black Hat conference here Thursday, give an attacker the ability to do any number of nasty things to a target machine, including forcing the download of an executable file, overwriting the URL field in the browser and overwrite secure HTTPS cookies with non-secure cookies.

In all, Hansen found 24 problems before he decided to stop looking. “I had basically had to stop the research because there were just too many issues. I didn’t have time to deal with anymore,” Hansen said.

A big part of the problem, Hansen said in an interview, is that browsers don’t enforce policies that would isolate the tabs in an open browser from one another. This allows an attacker who can control one of the tabs, say a normal non-SSL session, to also affect content in the other tabs, even if they’re using SSL. Hansen identified several techniques that enable him to watch an SSL-protected session and glean a lot of information about what the user is doing, based on timing certain parts of the Web session and knowing how long it takes for part of a site to load. He also can tell whether a user is logged in on a given site and use a specific technique to log the user out so he can then watch the login operation and steal the credentials.

“When you look at it, what does SSL really offer? What this means is that for the average user, against a determined adversary, there really is no protection,” said Hansen, who presented his findings at the Black Hat conference here Thursday. “People give SSL and TLS a lot of credit, when it shouldn’t have any at all.”

SSL is the main transport security used by millions of Web sites to protect data being sent from browsers to Web servers. It’s been shown to be vulnerable to a number of different attacks, including several man-in-the-middle attacks, which could be used in conjunction with some of Hansen’s techniques to completely compromise a supposedly secure Web session.

“The most important thing is that if an attacker can map out the domain ahead of time, he can get a really good feel for how the site is built,” Hansen said. “If there’s a side channel, I can force them to precache some of the content on the page so that I don’t see that again when they reload the page. Then, the only thing you’re seeing are the things that are interesting to the attacker. You can map out the user’s flow around the site and the attacker can force the user to make an SSL connection to them so they can tell which SSL and HTTP headers are being sent in which direction. It’s about narrowing down the number of bytes that are interesting.”

As troubling as the problems that Hansen found are, he emphasized that they don’t mean that the sky is falling.

“You still need to be a man in the middle first and there are probably easier ways to attack people once you are, but there are a lot of issues here,” he said. “If there was better jitter and padding in SSL, a lof of this wouldn’t even be possible.”

Source

Police have expanded their use of powers to force suspects to decrypt files by 50 per cent in the last year, figures released today reveal.

In the 12 months to March 31 this year, government officials approved 38 notices under Part III of the Regulation of Investigatory Powers Act, compared to 26 in the previous year.

The powers, known as section 49 notices, require suspects to hand over passwords or make files intelligible to investigators on threat of a two-year jail sentence, or five years where national security is concerned.

As well as obtaining more section 49 notices, police also expanded the range of crimes they were used to investigate.

In 2008/09 they were served in relation to counter-terrorism, possiession of indecent images of children and “domestic extremism” (a case involving activist attacks on animal testing labs). In the last 12 months, however, RIPA Part III was used to demand decryption in cases of insider dealing, illegal broadcasting, theft, excise duty evasion and aggravated burglary, the Chief Surveillance Commissioner Sir Christopher Rose said in his annual report.

Investigations into indecent images of children remained the “main reason” section 49 notices were served, he added.

Of the 17 notices obtained this year that have so far been served, six suspects complied and seven did not. The remainder are still being processed. One person suspected of possessing indecent images of children has been convicted for failing to hand over passwords.

The compliance rate was up on last year, the first full year since the powers were activated, when 11 out of 15 suspects served with a section 49 notice did not make their files intelligible to investigators.

Sir Christopher noted the discrepancy between 38 approvals granted by the National Technical Assistance Centre (NTAC) and the number of notices actually served. NTAC is a unit at GCHQ, the Cheltenham code-breaking agency.

“Notices, once approved, should be served without delay,” Sir Christopher said. “If delays continue, I will require an explanation.”

Last year The Register reported the case of the first man known to have been jailed for failing to hand over encryption keys to the police. “JFL” was a schizophrenic software developer initially charged with explosives offences that were later dropped. He was sectioned under the Mental Health Act during his prison sentence.

Source

Heartland Payment Systems, the victim last year of a massive data breach of sensitive card data, vowed after that devastating event to develop new security gear based on end-to-end encryption between itself and its merchants to prevent such a breach from occurring again. That’s now taking shape, but slowly.

“We have a long way to go,” acknowledges Heartland CEO Bob Carr, pointing out the so-called E3 payment terminals, intended for small-to-midsize customers, are but the first step, “with more advanced technologies coming in the summer” intended for use between Heartland’s network and much larger merchants that would require more back-end integration into processing systems. “We’re not ready to help all of them yet,” he acknowledges.

There is as of yet no end-to-end encryption requirement for debit- and credit-card processing, though the Payment Card Industry (PCI) Security Standards Council, which sets technical standards used by payment processors and merchants, is expected to weigh in on that topic in its upcoming PCI standard this October.

Unwilling to delay action after last year’s devastating discovery of a data breach that has so far cost it well over $100 million in fines and associated costs, Heartland has spearheaded its own multi-million-dollar end-to-end encryption technology effort to keep cybercriminals at bay. (Hacker Albert Gonzalez was caught and confessed to hacking Heartland’s processing network and much more, and this March was sentenced to 20 years in prison.

“Every single breach I know of wouldn’t have happened if our end-to-end encryption solution had been there,” Carr says. He believes Heartland is the first to come out with a commercial deployment of end-to-end encryption with merchants.

Carr says the definition of end-to-end encryption may end up varying, but in the case of Heartland, it means protecting card data, particularly the track data, as it’s being swiped at the merchant to the entry point to Heartland’s network, and encrypted on through Heartland’s network. However, this encryption now stops at the card brand point, such as Visa and MasterCard, and isn’t encrypted on through to the banking points.

Carr thinks the most vulnerable points that hackers will try to exploit are in the interconnections between merchant and payments processor, but he acknowledges that as the industry evolves to better protect these routes, hackers will undoubtedly look for the weakest link in the chain.

The E3 terminals, built by Voltage Security and Uniform Industrial Corp., were custom ordered by Heartland, which isn’t requiring its merchants to use them, but strongly recommending them.

“They do have to buy the devices,” Carr says, noting they range between $300 to $500, which Heartland will finance for six months if merchants have cash-flow issues. But one incentive for using E3 is a guarantee from Heartland that if merchants using E3 are breached, Heartland will cover fines and forensic costs related to any breach tied to the stand-alone terminals. Heartland is also offering free help to smaller merchants in filling out PCI standard conformance forms, something that can be technically bewildering to them.

One looming issue in end-to-end encryption is interoperability if the industry adopts more robust processes for protection through encryption. But Carr is optimistic the industry will meet the challenge, saying the PCI Security Standards Council “is listening hard and being responsive.”

Source