63% of orgs believe they can’t stop data theft

63% of orgs believe they can’t stop data theft

Infosec 2014: Datacentre security key to cloud security, says Google

Warwick Ashford

Wednesday 30 April 2014 The security challenges of the cloud are fundamentally the same as those of any in-house datacentre, says Peter Dickman, engineering manager at Google.

This means securing data in both can be tackled in the same way, he told attendees of Infosecurity Europe 2014 in London.

 “It is a question of adding as many layers of controls as possible without impairing usability,” said Dickman, which is the approach Google uses to continually evolve and improve security.
Although cloud computing is at an unprecedented scale, he said there are really no new security challenges in the cloud.
“Security is still about balancing controls with usability and, while it is not necessarily easy, it is also not impossible to achieve,” said Dickman.
Security professionals know there is no such thing as perfect security, but he said there are many things that can be done to ensure data in the cloud is as secure as possible.
Google, like most other cloud service providers, has had the advantage of building infrastructure with scalability and security in mind from the start.
“We recognised that devices could be compromised, some applications could be malicious and that we could not assume that users were security savvy, so we planned accordingly,” said Dickman.
First, this means that the computers in cloud datacentres are largely homogenous, making it quick and easy for service providers to update application software and security controls whenever needed.

“This homogeneity enables us to treat each datacentre like a single computer, which makes it easier to do security and get it right,” said Dickman.

Google uses a single, custom-built and security-hardened Linux-based software stack for all its servers in a single datacentre.
The servers are designed so they do not include unnecessary hardware or software to reduce the number of potential vulnerabilities.
This is important for cloud service providers, he said, as their business relies on preserving the trust placed in them as stewards of data belonging to hundreds of millions of users.
Although cloud computing tends to raise concerns about data security, Dickman said this approach was developed in response to the demand for access to data everywhere.
“People attempted to achieve this by making copies of data on portable media and mobile devices, but that was a security risk, and cloud computing essentially meets the need without the risk,” he said.
The next step, said Dickman, is to ensure physical security at the cloud datacentres, using multiple layers of access control technologies and processes.
“It is also important to build devices against possible malicious insiders, which is why our security teams build systems to check each other,” he said.
Also within the datacentre, Dickman said it is important to follow the principles of isolation, segregation and sandboxing, and deploy encryption wherever, and whenever possible.
“Encryption is no panacea, but it is worth the cost and Google is continually working to ensure our encryption algorithms are as fast and as secure as possible,” he said.
Unfortunately, many organisations still fail to keep things separate, said Dickman. “This is not rocket science, just tricky engineering,” he said.
Availability is another important component of security he said, but because cloud service providers take security seriously, they tend to build their datacentres to be fault tolerant.
“We test our fault tolerance by turning things off, which should work if systems have been designed and implemented correctly,” said Dickman.
Google has robust disaster recovery measures in place due to its ability to shift data access to other datacentres in various parts of the world, selected for their relatively high political stability.
Google does not store each user's data on a single machine or set of machines. Instead, the company distributes all data, including its own, across many computers in different locations.
The data is then split into chunks and replicated over multiple systems to avoid a single point of failure, and the data chunks are given random computer-readable only names as an extra measure of security.
Google also rigorously tracks the location and status of each hard disk in its datacentres, and it destroys hard disks that have reached the end of their lives in a thorough, multi-step process.
“No one knows yet how to build perfect security, but Google is continually working to make it better,” said Dickman.
All companies are faced with the security challenge of finding the correct balance between what is needed and what can be afforded, he said.
But Google, like most other cloud service providers, argues that because of the economies of scale, it is able to build and maintain security to a higher level than most companies could achieve on-premise.


http://www.computerweekly.com/news/2240219821/Infosec-2014-Datacentre-security-key-to-cloud-security-says-Google?asrc=EM_EDA_28719943&utm_medium=EM&utm_source=EDA&utm_campaign=20140430_Infosec%202014:%20Datacentre%20security%20key%20to%20cloud%20security,%20says%20Google_

Password Requirements Quick Guide

Password Requirements Quick Guide

Question: Which characters are required in my password?

Answer: That depends on how long it is. The shorter it is, the more restrictions there are. Here are the specific requirements:

Number of characters	Requirements
8-11	mixed case letters, numbers, and symbols
12-15	mixed case letters and numbers
16-19	mixed case letters
20 or more	Any characters you like!

Stanford recommends a password 16 or more characters long.

Longer passwords are inherently more secure because it takes hackers longer to guess them when employing a brute force method. So make your password 16 characters or longer!

Because they only require upper and lower case letters, passwords that are 16 characters or longer are much easier to type on a mobile device.

You may be thinking “How on earth can I come up with a password that long?!” It’s easy! Just select 4 random words. For example: orange eagle key shoe. That’s 21 characters including the spaces.

Now go forth and create your own awesome passwords and keep your account secure!

For more information, visit itservices.stanford.edu/service/accounts/passwords.

A guide to cloud encryption and tokenization

A guide to cloud encryption and tokenization

by Bob West - Chief Trust Officer, CipherCloud - Tuesday, 22 April 2014.

Cloud adoption shows every sign of continuing to grow. The sharing of resources helps businesses achieve savings and agility based on economies of scale but there’s a problem: cloud computing can also be an attractive target for cyber thieves.

Businesses using the cloud are now increasingly looking to security experts for help on how to protect their data against unwanted intrusion. With Edward Snowden’s continuing revelations on government spying, and a string of headline-grabbing incidents like the recent Heartbleed security vulnerability, many are calling 2014 the year of encryption.

In order to achieve the best cloud information protection strategy, enterprises must understand what information they use to run their enterprise and what sensitive data should needs protection in the cloud. Businesses migrating to the cloud are being advised to lock down any sensitive data before it leaves their premises, which is why more companies are deploying encryption.

To encrypt or not to encrypt

U.S. cloud providers like Google and Microsoft have been upgrading their server encryption levels. This reinforces the relevance of encrypting sensitive data in the cloud for security and privacy compliance worldwide.

Another factor to consider is only a small percent of a company’s data needs to leverage this technology. A pragmatic approach is to encrypt the sensitive data, such as personally identifiable information or research and development materials that could damage the company and or its customers’ reputation in the event of a breach. All data does not need be encrypted in the same way either. Additionally, for functionality’s sake, information such as credit card numbers may need their formats preserved in ways that address information does not.

But is encryption enough to protect private data? To answer that question, it’s vital to understand the encryption methods and know how they work together to keep data protected against unwanted intrusion.

Symmetric and asymmetric encryption

Most secure online transactions rely on asymmetric encryption to encrypt the tunnels as data moves across servers. This is used by online banking or shopping sites to secure the credit card details entered onto transactions page. It relies on a pair of keys – a public one, used to encrypt the data, and a private one, used to decrypt the data.

Yahoo! joined Google and Microsoft in upgrading HTTPS, the encryption standard used to protect these tunnels, from RSA 1024-bit to 2048-bit. This upgrade fortifies the transport layers to protect network environment.

As a complement, symmetric encryption, which relies on one key, provides data-centric protection and typically encrypts the information before it goes to the cloud. Using the industry standard of AES 256-bit, symmetric encryption scrambles the data and gives the keys to the enterprise. This enables enterprises to tighten control over access to the encrypted information.

One of the factors that influences a company’s decision on how to encrypt their data are the privacy regulations they must follow and desired levels of control to meet internal security and privacy policies. Faced with a valid legal order to decrypt and surrender internal data by a government, enterprises must comply with this request. However, this process is still transparent and does not cede decision-making to a third party.

Cloud encryption best practices

Like with any technology, there are common concerns and best practices to follow when securing data with encryption. The first pitfall is whether a business is using strong enough encryption – especially in light of recent security issues.

Encryption comes in different strengths, and choosing the right kind for each data field’s needs is vital to a successful cloud information protection strategy. As mentioned earlier, due to their higher level of sensitivity, customers’ credit card numbers require a higher strength of encryption than customer post codes for example. Failing to use a strong enough encryption method for protected data can result in compliance violations or data breaches – two costly consequences every enterprise wants to avoid.

Collaboration is generally a good thing but any kind of encryption method that gives a third party access to the encryption keys leaves the enterprise more vulnerable to a breach. A third party, for example, could have a security breach or fall victim to an insider threat and, should they ever receive a government request for data, customer information could be turned over without their knowledge or consent.

To ensure that only the business alone has the power to unlock data, keep exclusive control of the encryption keys. This way, even if data is leaked or stolen, it will remain illegible to unauthorised viewers. In the event of cloud surveillance, the intruder can’t decrypt the content without the key.

The beauty of encryption is that it can lock down data so that only authorised parties can read or use it. When implementing an encryption strategy, ensure the software retains data formats and uses methods that preserve the data’s searchability, sortability, reportability, and general functionality in the cloud.

Tokenization best practices

Instead of encrypting data, tokenization replaces the data itself with a placeholder. The data itself is securely stored within an enterprise’s perimeter, and only the token is transmitted. Like encryption, it plays a vital role in a company’s compliance strategy and reduces cloud-related PCI DSS and HIPAA scope by limiting the amount of data that is to be sent outside of the data centre.

However, tokenization has its pitfalls and enterprises should consider the solutions that can address them. The first issue is similar to the uses of a cloud service provider to encrypt their data for the enterprise. By allowing a third party to handle tokenization off-premises, it means handing over sensitive data to a third party and trusting them to secure that data in their own data centres. If tokenization is part of an enterprise’s cloud information protection strategy, do it on premises to retain more control over the data.

Is there such a thing as tokenizing too much or not enough? Tokenization requires enterprises to store their data separately in a data centre, so overuse can result in excessive consumption of that storage resource. With this in mind, only tokenise what is needed.

A word on compliance

Before committing to the cloud, businesses need to understand exactly what cloud information protection measures must be taken to remain in regulatory compliance. Here are a few:

In the UK, the Information Commissioner's Office (ICO) can impose financial penalties of up to £500,000 for companies that breach the Data Protection Act. Its guidance clearly puts the onus on the companies owning the data.

The EU has sanctioned both the Data Protection Directive of 1995 (46/ EC) and Internet Privacy Law of 2002 (58/EC), where businesses are required to notify data owners if their personal data is being collected, secure data from potential abuses, and only share data with the subject’s consent.

The PCI DSS is a global information security standard every company must consider if they are to protect their credit card and customer account data from unauthorised access and misuse.

What now?
Adopting a well-thought out cloud information protection strategy will give the enterprise full control when it comes to securing its enterprise’s sensitive data. Encryption and tokenization are vital to enabling regulatory compliance and the security and privacy of sensitive data. Used correctly, they can help enterprises stay safe in the cloud and conduct business without interruptions.

http://www.net-security.org/article.php?id=1995&

Security experts at Mandiant uncovered attackers exploiting the Heartbleed vulnerability to circumvent Multi-factor Authentication on VPNs.

Security experts at Mandiant uncovered attackers exploiting the Heartbleed vulnerability to circumvent Multi-factor Authentication on VPNs.

We have practically read everything about HeartBleed bug which affects OpenSSL library, we have seen the effects on servers, on mobile devices and also on Tor anonymity,  now lets focus on the possibility to exploit it to hijack VPN sessions.

Cyber criminals are trying to exploit Heartbleed OpenSSL bug against organisations to spy on virtual private network connections hijacking multiple active web sessions.

Security experts at Mandiant discovered attackers are exploiting the Heartbleed vulnerability to circumvent Multi-factor authentication on VPNs. The investigators have found evidences of the attack analyzing IDS signatures and VPN logs.

Considering that through an Heartbleed request the attacker could gain access to a limited portion of memory (64KB of memory for each Heartbeat request), in order to fetch useful data he needs to send a huge quantity of requests. This stream of requests was identified by IDS once it was written a signature specifically for Heartbleed.

During the intrusion observed by Mandiant the IDS detected more than 17,000 requests matching the pattern written for HearttBleed.

Mandiant confirmed that an unnamed organization suffered a targeted attack which exploited the “Heartbleed” bug in OpenSSL running in the client’s SSL VPN concentrator to remotely access organization’s internal network.

“This post focuses on a Mandiant investigation where a targeted threat actor leveraged the Heartbleed vulnerability in a SSL VPN concentrator to remotely access our client’s environment and steps to identify retroactively if this occurred to your organization.” reported the Mandiant official post.

The attacker is able to obtain active session tokens for currently authenticated users sending repeatedly malformed heartbeat requests to the HTTPS web server running on the VPN device. Once gained an active session token, the attacker successfully hijacked multiple active user sessions and deceived the VPN concentrator which considered it as legitimately authenticated.

“With an active session token, the attacker successfully hijacked multiple active user sessions and convinced the VPN concentrator that he/she was legitimately authenticated.”

“The attack bypassed both the organization’s multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software.” wrote Mandiant experts Christopher Glyer and Chris DiGiamo. 

The following evidence proved the attacker had stolen legitimate user session tokens:

1. A malicious IP address triggered thousands of IDS alerts for the Heartbleed vulnerability destined for the victim organization’s SSL VPN.
2. The VPN logs showed active VPN connections of multiple users rapidly changing back and forth, “flip flopping”, between the malicious IP address and the user’s original IP address.  In several cases the “flip flopping” activity lasted for multiple hours.
3. The timestamps associated with the IP address changes were often within one to two seconds of each other.
4. The legitimate IP addresses accessing the VPN were geographically distant from malicious IP address and belonged to different service providers.
5. The timestamps for the VPN log anomalies could be correlated with the IDS alerts associated with the Heartbleed bug.

The hackers once gained the access to the internal network of targeted organization attempted to move laterally and escalate his/her privileges.

Attacks like the one uncovered by Mantiant will increase in the next weeks, it is necessary to immediately identify and upgrade the component that make use of the flawed library.

Pierluigi Paganini
(Security Affairs –  VPN, Mandiant)

IT snapt Heartbleed niet

17 apr. 2014 door Evan Schuman                    

17 apr. 2014 door Evan Schuman

Opinie - De reactie van IT-afdelingen op het Heartbleed-lek is bijna net zo verontrustend als het gat zelf.

Het patchen van OpenSSL, het installeren van nieuwe certificaten en het veranderen van wachtwoorden is prima, maar de kritieke follow-up ontbreekt. We zouden beter moeten nadenken over het omgaan met security van missiekritische software.

Als je er als buitenstaander naar kijkt, is Heartbleed een godsgeschenk voor IT: het is een belangrijke wake-up call voor fundamentele problemen in de omgang met internetsecurity. Als iedereen nu wakker wordt, gaat security er flink op vooruit. Maar als deze kwetsbaarheid gewoon wordt gepatcht en verder genegeerd, dan zijn we ten dode opgeschreven. (Ik denk al jaren dat we er allemaal aan gaan, maar nu heb ik daar meer bewijs voor in handen.)
Laten we eens teruggaan hoe Heartbleed ontstond. Het is kennelijk per ongeluk twee jaar terug aangemaakt door de Duitse softwareontwikkelaar Robin Seggelmann. In een interview met de Australische Sydney Morning Herald, zei Seggelmann: "Ik werkte aan het verbeteren van OpenSSL, voerde verschillende bugfixes door en voegde een aantal nieuwe features toe. Voor een van deze nieuwe functies miste ik, helaas, de validatie van een variabele."
Nadat Seggelmann de code had ingestuurd, heeft de reviewer de missende validatie kennelijk niet opgemerkt en is de code van de developmentfase in de productieversie terecht gekomen. Seggelmann stelt dat de fout zelf "vrij triviaal" is, terwijl de consequenties dat allerminst zijn . "Het was een simpele programmeerfout voor een nieuwe feature. Helaas heeft dit plaatsgevonden in een voor security belangrijk gebied."
Wat Segelmann deed was perfect te begrijpen en te vergeven. Het grote probleem is dat er onvoldoende veiligheidsmaatregelen in het systeem zijn ingebouwd om simpele wiskundige fouten te voorkomen. Als de checks and balances in het systeem zo fragiel zijn dat een typfout alle getroffen securitymaatregelen kan ondermijnen, zijn er een aantal fundamentele zaken die oplossing behoeven. Laten we niet vergeten dat toen Robert Tappan Morris in 1988 zijn Internet Worm losliet, het hele internet crashte. Ook dit was het resultaat van een rekenfout. Hij had nooit voorzien dat servers zouden crashen, maar toch gebeurde dit.
CIO David Schoenberger van securityleverancier Transcertain stelt dat de echte securityzwakheid waar we hier mee te maken hebben een teveel aan vertrouwen is onder IT-professionals. Persoonlijk denk ik dat je daaraan kunt twijfelen, maar Schoenberger maakt wel een interessant punt.
"Dit gaat mensen opnieuw doen nadenken over wat we eigenlijk doen. Er worden zoveel dingen over het hoofd gezien en als vanzelfsprekend ervaren. In de IT-wereld hebben we te lang op vertrouwen geleund", zegt hij. "Kijk maar naar de miljardenbedrijven die vertrouwen op peer-reviewed open-source. We nemen niet meer de moeite om zelf de proef op de som te nemen. Omdat het meestal werkt en het, in onze perceptie, goed werkt, slaagt het voor onze tests. Op dit moment heeft open-source gefaald, maar het had ook een commercieel product kunnen gebeuren. Dit had overal kunnen plaatsvinden."


Microsoft vertrouwt al jaren op crowdsourcing. Een softwareproduct wordt voor miljoenen mensen gelanceerd en Microsoft vertrouwt erop dat de community de gaten vindt. Ik grapte eerder daarover dat Microsoft kwaliteit op plaats 1.1 zet. Het idiote is dat de strategie van Microsoft werkt. Maar hoe kon Heartbleed twee jaar lang rondspoken zonder dat een securityonderzoeker het opmerkte?

Sommigen zijn ervan overtuigd dat mensen en instanties ervan hebben moeten weten. De NSA is beschuldigd van kennis en misbruik van het gat. Deze beschuldiging leidde tot een ontkenning. In een statement liet men weten: "De federale overheid was niet op de hoogte van de recent geopenbaarde kwetsbaarheid in OpenSSL totdat deze publiek gemaakt werkt in een cybersecurity rapport afkomstig uit de private sector."
Er zijn twee onderdelen van het volledige statement (lees die hier) waarin de geloofwaardigheid van de NSA te betwisten valt. Allereerst is het idioot om te verklaren dat niemand van de federale overheid (dus de CIA, FBI, NSA, het leger en 200 overheidsinstellingen) ook maar iets van het gat wist. Hoe weet je zeker dat een securityspecialist van het leger het niet wist? Niet ieder gat dat wordt ontdekt wordt noodzakelijkerwijs gerapporteerd aan het senior management. Als ze hadden gezegd "voor zover ons bekend" of "we kunnen het niet met zekerheid stellen dat, maar...", dan zou dat wel plausibel zijn. Het is alsof mijn tienerdochter vertelt dat niemand op haar school drinkt of drugs gebruikt.
Mijn tweede punt bij het NSA-statement heeft betrekking op de laatste regel: "Tenzij er een heldere noodzaak is vanuit nationale veiligheid of wetshandhaving, brengen wij zulke kwetsbaarheden altijd naar buiten." Niets in het statement wijst erop dat zo'n noodzaak er in dit geval was. Het is vergelijkbaar met mijn dochter die na haar eerdere uitspraak zegt: "Ik vertel altijd de waarheid over zulke dingen, tenzij het mijn vrienden in de problemen zou brengen, dan zou ik wel liegen."
Ik ben nooit een fan van het toevoegen van extra bureaucratie, maar het is misschien tijd om formele controlerende procedures in te stellen - liefst meerlaags - waarbij mensen actief en transparant onderzoek doen naar mogelijke gaten. Peer review is goed, maar voor iets cruciaals als internetbeveiliging, zijn we allang het punt gepasseerd waarbij er soms iets op mag duiken. We moeten er proactief naar op zoek.


Evan Schuman was eerder hoofdredacteur van techsite StorefrontBacktalk en columnist bij CBSNews.com, RetailWeek en eWeek. Tegenwoordig schrijft hij columns voor zustersite Computerworld.com.

Rapporteren volgens Solvency-II nog 'grote uitdaging'

Risicomanagement         

Hoewel bijna 80 procent van de Europese verzekeraars denkt aan de vereisten van Solvency-II te kunnen voldoen voor de naar 1 januari 2016 verschoven invoering, vormen de rapportagevereisten nog een 'enorme uitdaging'.

Foto: 123 RF

Dat beeld komt naar voren uit de European Solvency II Survey van EY, waarbij 170 verzekeringsmaatschappijen in 20 Europese landen zijn onderzocht. De Nederlandse, Britse en Scandinavische verzekeraars zijn het best voorbereid, terwijl de Franse, Duitse, Griekse en Centraal- en Oost-Europese verzekeraars er minder vertrouwen in hebben.

Uit het onderzoek komt naar voren dat de verzekeraars klaar zijn voor de implementatie van Pilaar 1 en voldoen aan de meeste vereisten voor Pilaar 2, het governance-systeem. Pilaar 3, de rapportagevereisten, vormt volgens de onderzoekers nog steeds 'een enorme uitdaging'.

Minder goed voorbereid
De opschorting van de deadline voor implementatie van Solvency II tot 2016 heeft volgens EY onder verzekeraars tot een groter vertrouwen geleid dat zij op tijd aan de vereisten kunnen voldoen. Wel wordt duidelijk dat sommige van hen minder voorbereid zijn dan zij zelf hadden verwacht.

Volgens EY-partner Paul de Beus hebben veel maatschappijen hun plannen simpelweg met minstens een jaar uitgesteld, wat deze partijen nu wel eens in de problemen zou kunnen brengen. Hoewel verzekeraars er geen twijfel over laten bestaan dat zij de effectiviteit van hun risicomanagement proberen te verbeteren, dient er wat betreft rapportage, data en IT nog wel het een en ander te gebeuren.'

Pilaar 1 en 2
Verzekeringsmaatschappijen lijken over het algemeen goed voorbereid te zijn op alle onderdelen van Pilaar 1, waarbij de Franse, Nederlandse en Italiaanse verzekeraars vrijwel volledig aan de eisen zullen voldoen. De Griekse, Portugese en Centraal- en Oost-Europese verzekeraars zijn minder voorbereid. Bijna 85 procent van de respondenten geeft echter aan dat zij wat betreft de effectiviteit en/of efficiëntie bij het voldoen aan de vereisten op grond van Pilaar 2 nog ruimte voor verbetering zien.

De Beus: 'Verzekeraars weten dat zij de inbedding van een risicocultuur in de eerste lijn effectiever moeten aanpakken. De top-4 van verbeteringen waarvan verzekeraars hebben aangegeven dat deze de effectiviteit van hun risicomanagement zouden kunnen verhogen, hebben allemaal te maken met de interactie met de eerste lijn.'

Risicobeoordeling
'De veranderingen scoorden echter ook hoog als het ging om hoe moeilijk het zou zijn om ze te realiseren. Ondanks dat Nederland het verst is met de implementatie van de Own Risk & Solvency Assessment (ORSA), heeft de ORSA oefening 2013 van DNB nog wel een aantal bevindingen opgeleverd die verzekeraars kunnen gebruiken bij het maken van de Eigen Risico Beoordeling die sinds dit jaar verplicht is. Ook blijkt uit de beoordeling van DNB dat nog steeds slechts de helft van de verzekeraars het kapitaalbeleid voldoende inzichtelijk heeft kunnen maken.'

Verslaggeving overgang
De Beus zegt dat de mate waarin de maatschappijen klaar zijn voor implementatie sinds 2012 amper is verbeterd. 'Onzekerheid over de implementatie en herhaald uitstel wat betreft het tijdpad kunnen hiervoor een verklaring zijn maar het is van belang om deze projecten in 2014 voorrang te geven.'

'Gezien de huidige status moet de overgangsverslaggeving over 2015 grotendeels handmatig worden gedaan. Dat is geen wenselijke situatie gezien het feit dat Nederlandse verzekeraars al in 2015 verplicht zijn diverse kwartaal- en jaarstaten op Solvency II grondslagen en richtlijnen aan DNB te rapporteren.'

Data en systemen
De gereedheid van de data en systemen voor Pilaar 3 blijft volgens EY nog steeds achter op Pilaar 1 en 2. Circa 25 procent van de verzekeraars heeft een systeem geselecteerd om aan de vereisten van Pilaar 3 te kunnen voldoen. Daarnaast geeft tweederde van de respondenten aan dat de data en systemen er niet op zijn ontworpen om buiten de normale verslaggevingscyclus om ORSA's uit te voeren.