M2M and RFID

This report evaluates the working aspects of M2M along with the details of RFID, provides deep insights into telecommunication technologies, reviews the latest developments within M2M, and provides further analysis through in-depth case study examples.


Machine-to-Machine (M2M) communications and Radio Frequency ID (RFID) together represent a means of direct communication between connection hardware and the object that needs monitoring: the information about its status of performance is directly sent to a computer system without the need for human intervention. This makes automation of processes or consumer action possible. 

The technology that utilized originates largely in the manufacturing and industrial processes industry, where physical assets networking have been done for decades. The goal of M2M-RFID is exactly as of a plant-floor automation systems or remote-monitoring solutions: it evolves getting information from sensors in a device and transmitting it to an IT network.


More here : http://www.pr-inside.com/machine-to-machine-m2m-and-rfid-r1788263.htm

eInvoice in Turkey

The eInvoice project of Turkey has become official on the 5th of March, 2010 and it appeared in the Official Gazette of Turkey no 27512 Sequence No 397 entitled "Tax Procedure Law".

All the technical information related to this project is available from http://www.efatura.gov.tr 

According to this law, if an organization wishes sent eInvoice to Revenue Administration, it has to comply with UBL schemas as developed by UBL TRLSC.

Minutier central électronique des notaires de France (MICEN) (norme simplifiée n° 55)

Une norme simplifiée relative aux traitements automatisés de données à caractère personnel mis en œuvre par les notaires a été adoptée. Elle permet la conservation des actes authentiques sur support électronique au sein du Minutier central électronique des notaires de France (MICEN) (norme simplifiée n° 55)

Seules les informations suivantes relatives peuvent être collectées :

• Les informations relatives à l'acte :

― la date de l'établissement de l'acte définie par le notaire rédacteur, le numéro de chrono au sein de l'office, la nature de l'acte (vente, donation, ...), l'intitulé de l'acte ;
― la représentation textuelle ou structurée de l'acte, l'image au format pdf/a permettant la représentation à l'écran de la partie de l'acte ;
― l'image des annexes ;
― la signature manuscrite (date, lieu de recueil ; portée de la signature ; image de la signature), du notaire participant, des parties et témoins du notaire participant, du clerc du notaire participant, la signature électronique du notaire participant, la signature manuscrite du notaire instrumentaire, des parties et témoins du notaire instrumentaire, du clerc du notaire instrumentaire, la signature électronique du notaire instrumentaire ;
― l'établissement du notaire instrumentaire/participant : adresse, numéro CRPCEN, raison sociale ;
― les parties à l'acte (personne physique) : qualité, état civil (civilité, nom, prénoms, date de naissance, commune, date, département de naissance), adresse, profession, régime matrimonial, nom du conjoint ;
― les parties à l'acte (personnes morales) : qualité, raison sociale, catégorie juridique, adresse (siège social) situation RCS, immatriculation, sigle de la société, date et lieu de dépôt des statuts.

• Les informations relatives au dépôt de l'acte :

― le lieu de stockage ;
― le numéro CRPCEN de l'office déposant ;
― l'identifiant du notaire instrumentaire ;
― le numéro d'ordre généré par le MICEN ;
― la date de l'archivage de l'acte dans le MICEN.

• Les informations relatives aux biens en cas d'actes soumis à publicité foncière :

― l'adresse, le complément adresse (bâtiment, résidence, étage.) voie (numéro, type, nom) lieudit, code postal, pays.

• Les informations relatives à la mention :

― la date de l'archivage de la mention dans le MICEN ;
― le numéro d'ordre de l'acte ;
― la date de l'établissement de la mention définie par le notaire rédacteur ;
― l'index, nature et description de la mention.

• Les informations relatives aux annexes à l'acte :

― l'intitulé et description du document.

• Les informations relatives à la preuve du dépôt :

― l'information sur la preuve du dépôt et sur son émetteur ;
― le numéro CRPCEN de l'office auquel est destinée la preuve ;
― l'identifiant du notaire déposant.

• Les informations relatives aux opérations d'administration du système :

― le nombre d'actes déposés et le volume occupé ;
― les accès administrateurs ;
― le code porteur clé Real notaire et administrateur.


Source : http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT000021961639&dateTexte=&categorieLien=id

Cross-site scripting vulnerabilities is an issue for modern browsers and they start to cope

Wikipedia explains cross-site scripting vulnerabilities (XSS)

Attackers intending to exploit cross-site scripting vulnerabilities must approach each class of vulnerability differently. For each class, a specific attack vector is described here. The names below are technical terms, taken from the cast of characters commonly used in computer security.

Non-persistent:

1. Alice often visits a particular website, which is hosted by Bob. Bob's website allows Alice to log in with a username/password pair and store sensitive information, such as billing information.
2. Mallory observes that Bob's website contains a reflected XSS vulnerability.
3. Mallory crafts a URL to exploit the vulnerability, and sends Alice an email, enticing her to click on a link for the URL under false pretenses. This URL will point to Bob's website, but will contain Mallory's malicious code, which the website will reflect.
4. Alice visits the URL provided by Mallory while logged into Bob's website.
5. The malicious script embedded in the URL executes in Alice's browser, as if it came directly from Bob's server (this is the actual XSS vulnerability). The script can be used to send Alice's session cookie to Mallory. Mallory can then use the session cookie to steal sensitive information available to Alice (authentication credentials, billing info, etc) without Alice's knowledge.

Persistent attack:

1. Mallory posts a message with malicious payload to a social network.
2. When Bob reads the message, Mallory's XSS steals Bob's cookie.
3. Mallory can now hijack Bob's session and impersonate Bob.

Framework:

A Browser Exploitation Framework could be used to attack the web site and the user's local environment.

XSS protection are possible in new browsers sometimes like options. It can cost you performance bur you will win security. It is your choice.

More : http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.microsoft.com/windows/internet-explorer/features/safer.aspx

http://www.computerworld.com/s/article/9149922/Chrome_apes_IE8_adds_clickjacking_XSS_defenses

Orange blogs on PCI DSS

What is PCI DSS?

It stands for the Payment Card Industry Data Security Standard and was created by the PCI industry body that represents the five major payment brands: American Express, MasterCard, Visa, JCB and Discover. Essentially PCI DSS is a security standard that focuses on the information security of credit card data: the cardholder's name, credit card number and the expiry date. The PCI created the standard in 2005 to have a unified security standard for the whole industry. Previously each payment brand had its own security standard, making it difficult for merchants to implement. Because the PCI DSS draws from these multiple security standards, it isn't really a new standard as such, rather a consolidation of best practice in information security for cardholder data.

Why is PCI DSS important for enterprises?

Quite simply, it is mandatory to be PCI DSS compliant if you handle credit card data and there are penalties if you don't comply with the standard. For example in the U.S., American Express directly imposes penalties on merchants: $50,000 if non-compliant, $150,000 after 30 days, $200,000 after 60 days and after 90 days, the merchant actually loses its right to handle credit card data. The deadlines for compliance are set by the payment brands and depend on the transactions annually processed by an organization. In the U.S. the level 1 firms, which handle more than 6 million transactions, already need to be compliant and other countries and company sizes are following suit.

Does it just apply to companies that take credit card data?

No it applies to any company that handles credit card data at any point. For example, network service provider and hosting companies will need to be compliant if credit card data travels over their network or is stored in their data center, respectively.  Because of this, it affects many different companies, not just the merchant who takes the credit card.

What steps do I need to take to become compliant to the standard?

The first step is to carry out a scoping exercise to allow you to identify where cardholder data is held, transmitted or processed. The standard only applies to these areas, so it is important that you focus your attention on where it matters. The second step is to carry out an assessment of how close you are to being compliant, such as what security you already have in place and how much work is required to fill in the gaps. This will allow you to draw up an action plan and carry out the necessary work. The final step is the assessment: some companies need to fill in a self-assessment questionnaire (SAQ) and this can be reviewed by an external Qualified Security Assessor (QSA) that will be able to certify the company to PCI DSS (Visa Canada, for example, imposes SAQ to be reviewed by a QSA). Others need to be assessed onsite by a QSA.

Source : http://blogs.orange-business.com/live/

Que sont devenus les produits dérivés?

Comme le rappelait en 2002 Warren  Buffet :

“Nous essayons de vous prévenir du risque d’une sorte de méga-catastrophe, … concernant les contrats de produits dérivés d’un montant énorme, constitués de  créances qui ne correspondent à rien et qui risquent de dégringoler.  À notre avis,  les produits dérivés sont des armes financières de destruction massive, portant des dangers qui, tout en étant latent, sont potentiellement létales.”

Vous pouvez relire à cett occasion l'article de Paul Farrell publié dans Market Watch, les chiffres étaient éloquents :

• PIB U.S.                     15 trillion $
• Budget fédéral U.S.       3 trillion $
• Dette U.S.                    9 trillion $
• Valeur total mondial des actions émises : 100 trillion $
• Évaluation du montant des produit dérivés en 2002 par BIS : 100 trillion $
• Évaluation du montant des produit dérivés en 2007 par BIS : 516 trillion $

Depuis les informations publiées sur le sujet ce sont taries! Pourtant les enjeux sont colossaux.
Appel à témoignagne.......... 

Flurry has an interesting report iPhone and Android applications

Source : http://venturebeat.com/2010/02/12/ipad-app-development-explodes-says-flurry-report/

More M2M from Orange Business Live

As anyone attending last year's Orange Business Live event will remember,M2M is growing into quite a phenomenon. Ten years ago, it was a smart concept with few deployments behind it. These days, businesses across many vertical sectors are using it to lower production costs, optimize the supply chain, lower energy consumption and increase operational efficiency. How many M2M devices are we talking about? Globally, about 412 million within four years according to the latest figures. There's an interesting overview of embedded M2M as the pervasive Internet in this M2M trends podcast.

About 1.5% of cellular network connections worldwide are used for M2M applications, showing that there's a great deal of headroom in the network for more. Utility metering is expected to become the most widespread application, offering lowered operational costs to utilities and more control over energy consumption to consumers. We looked at the main issues surrounding smart metering in this blog. But, hard on its heels will be the maturing of healthcare remote patient monitoring solutions, intelligent transport systems, manufacturing monitoring and security applications such as vehicle tracking and CCTV. We have written about telematics in this blog and recorded this podcast with Romain Jourdan, an Orange expert in in-car telematics.

M2M rubber hits the road

In terms of personal security, the European Commission's eCall initiative is probably the furthest-reaching of its kind undertaken. With nearly 40,000 people killed on roads every year, and 1.7 million injured in road accidents in the European Union alone, M2M has the potential to be the biggest road safety technology of all time. Forget ABS, power-assisted steering or traction control, the EC's eCall promises a very simple benefit to the motorist involved in an accident: time saved equals lives saved.

M2M would automatically place a call to the emergency services in the case of an accident and the location of the vehicle can be found immediately using GPS. The first few minutes of any accident are crucial to the chances of survival of occupants who are facing grave injuries, and eCall is projected to save halve response times in cities and reduce them by 60% in the countryside. You can see how it works in this video. 

This principle can be applied to Intelligent Transport Systems (ITS) that promise to reduce vehicle energy consumption by pointing out the shortest route, alert motorists and emergency services to accidents or transport blockages, and also adapt lighting to the prevalent road conditions. Such adaptive lighting takes a feed from local weather reports and dims lights in good conditions, saving local councils money and giving them back budget that's better spent elsewhere, particularly as governments respond to the global recession. ITS also promises to improve the efficiency of any enterprise that relies on transporting products in specific environments by the most direct and economical route possible, automatically pay road tolls, and dynamically responding to changes in transport conditions thanks to M2M.

Modulating the cost

What can we expect from the technology that actually delivers these possibilities, the M2M module? Although the module market has been under pressure to deliver improved designs that conform to the requirements of different applications, there are a number of general trends carrying through from 2009. These include the integration of greater functionality like satellite integration, WiMAX modules, lowered power consumption and probably the biggest development of all - a move from 2.5G to 3G network support. This increases the available bandwidth and opens up a swathe of new applications that require higher data speeds. It's also actually more economical for service providers to supply coverage in densely populated areas using 3G as it makes better use of the spectrum. It follows that over time, the cost of operating an M2M 3G network could fall as service providers reduce prices due to this economy of scale.

Also on the list for module developers is building in greater reliability and compatibility. Many machines that are connected over the M2M network by modules have long life-spans (think of industrial machinery or even just cars) during which time technology moves on. Therefore, there's also been a focus on making the functionality of modules flexible by developing units that are FOTA (Firmware Over The Air) upgradeable. Using the very network normally required for powering an application, an M2M module can automatically upgrade itself to optimize its effectiveness and stay ahead of future requirements. 

Source ! http://blogs.orange-business.com/live/

Secured mail with Gmail and Postini

Message security service sends your outbound messages to recipient mail servers depending of your option :

Send only SMTP: No TLS encryption, and all messages are delivered via SMTP.

Send by SMTP or TLS (Recommended): This is the recommended setting. Messages sent via TLS are delivered via TLS to the recipient. Recipient servers that do not support TLS will receive their mail delivered via SMTP. All other messages are delivered via SMTP.

Send by TLS if possible: This delivers all messages by TLS when possible. Recipient servers that do not support TLS will receive their mail via SMTP.

Send only TLS: Send all messages by TLS. Mail sent to recipient servers that do not support TLS will be deferred.

Send and Deliver TLS: Messages sent via TLS are delivered via TLS to the recipient. If the recipient does not support TLS the message will be deferred. All other messages are delivered via SMTP.

Source : http://www.postini.com/webdocs/admin_msd/wwhelp/wwhimpl/js/html/wwhelp.htm?href=logsearch.20.6.html#2976107

Ten steps to kill open source project

#1 is to make the project depend as much as possible on difficult tools. He noted that most companies have no real trouble employing this technique, since it makes good use of the tools they have around anyway. Community-resistant projects should, for example, use weird build systems not found anywhere else. A proprietary version control system is mandatory. Even better are issue trackers with limited numbers of licenses, forcing everybody to use the same account. It's also important to set up an official web site which is down as often as it's up. It's not enough to have no web site at all; in such situations, the community has an irritating habit of creating sites of its own. But a flaky site can forestall the creation of those sites, ensuring that information is hard to find.
2: Encourage the presence of poisonous people and maximize the damage that they can create. There is a special technique to the management of these people which goes something like this:

1. Take pains to argue with these people at length and to denounce them on the project lists.
2. Eventually, they should be banned from the community by fiat; it's important to avoid any sort of community process here.
3. The banned people will take their flames elsewhere. Follow them and continue to argue with them in those external sites.
4. Eventually the community will complain about this behavior; respond by letting the poisonous people back in. Then go back to step 1 and do it all over again.

Properly managed, one effective poisonous person, according to Josh, can wipe out a community of hundreds.
3: Provide no documentation. There should be no useful information about the code, build methods, the patch submission process, the release process, or anything else. Then, when people ask for help, tell them to RTFM.
4: Project decisions should be made in closed-door meetings. An OK start is to have online meetings with very short notice, though, for best effect, they should be at a time which is inconvenient in the time zones where most community members are to be found. Better is to have meetings via conference call: that excludes about a third of the planet due to sleep requirements, and, for extra value, also excludes a number of people who are at work who might have been able to participate in an online meeting. Best, though, is to hold meetings in person at the corporate headquarters.
5: Employ large amounts of legalese. Working with the project should involve complex contributor agreements, web site content licensing, non-disclosure agreements, trademark licenses, and so on. For full effect, these documents should all be changed without notice every couple of months or so.
6: The community liaison must be chosen carefully. The optimal choice is somebody reclusive - somebody who has no friends and really doesn't like people at all. Failing that, go with the busiest person on the staff - somebody with both development and management responsibilities, and who is already working at least 70 hours per week. It's important, in this case, to not remove any of this person's other responsibilities when adding the liaison duty. It can also be effective to go with somebody who is unfamiliar with the technology; get a Java person to be the liaison for a Perl-based project. Or, if all else fails, just leave the position vacant for months at a time.
7: Governance obfuscation. Community-averse corporations, Josh says, should learn from the United Nations and create lengthy, complicated processes. Keep the decision-making powers unclear; this is an effective way to turn contributors into poisonous people. Needless to say, the rules should be difficult or impossible to change.
8: Screw around with licensing. Community members tend to care a lot about licenses, so changing the licensing can be a good way to make them go elsewhere. Even better is to talk a lot about license changes without actually changing anything; that will drive away contributors who like the current license without attracting anybody who might like the alleged new license.
9: Do not allow anybody outside the company to have commit access, ever. There should be a rule (undocumented, of course) that only employees can have commit rights. Respond evasively to queries - "legal issues, we're working on it" is a good one. For especially strong effect, pick an employee who writes no code and make them a committer on the project.
10: Silence. Don't answer queries, don't say anything. A company which masters this technique may not need any of the others; it is the most effective community destroyer of them all.

Source is : http://lwn.net/Articles/370157/