Blog

It has been wonderful to discuss with software vendors both large and small their transition to the cloud.  And as you would expect, security is very much “top of mind”.

After reading a post by Olivier Coudert, I decided to provide a high-level description of some of the main techniques used to secure a cloud implementation.  Hopefully it’s useful when considering a cloud (Infrastructure-as-a-Service, IaaS) or platform (Platform-as-a-Service, PaaS) provider.

Most of our customers use our platform with the Amazon cloud.  And so the infrastructure portion of this discussion will be taken from their implementation, described in more detail in their white paper.  (One of the primary reasons why we built our platform on top of Amazon’s infrastructure is because of their security.)

The areas to consider are illustrated below.  The user (client) on the left, and the public or private cloud on the right form the two end-points.  The communication network in between (what we used to call “the cloud”, before there was “The Cloud” ) is the other key component.

End-points to Cloud Security

The Cloud - Physical Security

This is the most fundamental of considerations.  Not only is it important if your data is valuable, but if you’re in a public cloud consider what else could be stored and valued in the same physical location.

The Amazon Cloud boasts extensive physical security measures, protocols, and technology, including “military grade perimeter control berms” and other “natural boundary protection”.

The Cloud - Logical Security

Firewall

Many breaches of security come from bots pinging IP addresses on multiple ports, mechanically looking for a way to get in somewhere (Port Scanning).

This type of attack is prevented at the Firewall:

(i) Close all ports except those that are to be used.  And only open those when they are actually used.

(ii) Restrict access by the protocol used (http, ssh, etc.)

(iii) Restrict access to only known client IP addresses.

In addition to this, AWS detects port scanning, stops it and blocks it.  Counter measures are also in place to protect against Distributed Denial of Service (DDoS) and Man In the Middle (MITM) attacks.

Operating System (Host and Guest)

Operating System Security

The Host Operating System that resides on the actual hardware needs to have strong key access to a limited number of Administrators.  No one else should have access at this level.  And those that do have access should only have it on a limited basis and only when they are doing actual work.

Guest OS’s (the virtual instances that are actually used by the hosted software) are isolated from the Host by the hypervisor (which also provides isolation between running instances).  Unprivileged Access to these instances should only be allowed via token or key-based authentication.

Key control is paramount for success at this level.

Data - Backup & Encryption

All stored data should be redundantly backed up, ideally (as with AWS) in multiple physical locations.  In addition, data can be encrypted on the remote instance.  In fact, encryption can be taken down to a very low level, but performance trade-offs come into play very quickly.

The Network

Other than protection from threats residing elsewhere on the network, data interception should be protected against.  Therefore, data traveling across the network should be encrypted.  In our case, we implemented communication and data transfer protocols that use AES-128 symmetric key encryption for all data sent between the client and the cloud server.

The User

After all of the above (and much more) has been put in place, we still need to provide access to users (customers) outside of the firewall.  And so we need to know who the users are, and to be able to confirm that they are indeed who they say they are.

In order to scale the business, the authentication and validation process must be automated and built into the on-boarding and access process.

Fortunately, as we’re dealing in a business-to-business environment, the easiest and most reliable way to automatically confirm identity is via an email validation process during user on-boarding.

Once validated and prior to accessing the cloud, the user’s identity should be authenticated again using the email address (or a username linked to the email address) and a password.

On the Xuropa Platform, we go one step further and add an additional security protocol to ensure that only the previously authenticated user can gain access to the cloud from a detected IP address.

Life’s a Trade-off

These are just a few of the techniques employed - when it comes down to it, anything is possible.  However, people need to have access, and in order for businesses to run, access needs to be straight forward for the user, monitored, controlled, and automated.

In architecting our platform, security is paramount, which means we have to put a great deal of effort into automation and the user experience (UX) design.

How are you securing your cloud processes?  And what are your concerns related to security?

Posted under Xuropa

In response to a cloud computing question I posted to an online forum discussion a concern was raised about security.  Here is the unedited response in full:

“I think cloud computing is extreamly dangerous. There are enough problems with viruses now. IF people were able to exploite holes in componants use din cloud modules or even write systems with back doors in would anyone be sure thyey have a sucure or safe system?”

As I noted in previous posts, security is indeed one of the key drivers of the adoption of cloud computing.  And trust will be a crucial ingredient in the “crossing of the chasm” of this technology and use model.

There is always mistrust of new technologies.  (Did you know that in the very early days of the motor car some scientists believed that passengers would suffocate at speeds over 20 mph?)  Some mistrust is well placed and drives innovative counter measures.  Others will need greater familiarity with the technology and leaders to follow.

To address the first aspect of the posters concern though - viruses and their contagion.

For a virus to be communicated three things need to occur.

1. Placement of the virus at the source.
2. Inadvertent download of the virus by the user.
3. Execution of the virus on the local machine.

There are three parties one could imagine placing the virus within the remote hosted application in the cloud: the cloud computing host company, the vendor of the hosted software, and users of the hosted software.  For a cloud computing company to go to all of the time and expense in developing sophisticated cloud computing platforms such as Xuropa’s Online Labs just to spread a virus is nonsensical.  Like-wise, for the owner of the electronic design software to place a virus within the Online Lab they are using does not make any sense whatsoever.  The last suspect, other users, could have the motive, but they will not have the means.

Consider the use model of a Cloud Computing-based EDA tool in the context of a Xuropa Online Lab as an example.  Every time the remote tool is accessed through a lab session, the environment is provisioned fresh and new from an image that is created by the tool vendor and Xuropa engineers for the Online Lab.  This image is inaccessible to a user.

While the session is active, only users that are explicitly invited into the lab session can have access to the work being carried out by the person who initiated the session.  There is no way for someone to sneak in via a “backdoor”.

If the user was malicious and did upload a virus to the Online Lab they would be very disappointed.  After every lab session has ended all data is erased, all processes on the lab are terminated and a thorough clean of the remote environment is carried out.

The Online Labs hosted on the Xuropa Platform today are even more secure in that they do not provide any upload or download capabilities by design.  No code is executed locally.  This talks to the gradual progression to the cloud of a previous post.  There are great benefits to be gained by leveraging cloud computing without leaping straight into design and development.  Training, demonstrations, workshops, pre-evaluation, and technical support to name just a few.

Which brings me to a follow up observation: mailing of CD’s for evaluation.

Today I opened the EDA Tech Forum magazine and it contained a CD from a nameless EDA vendor.  At the bottom of the CD is written “Every effort has been made to ensure that this disk is virus-free. “XYZ Company” is not responsible for any disruption, damage and/or loss to your data or system that may occur while using this CD.  As with all software we recommend running a virus scanner before use.”

I’m sure that this CD is fine.  The probability of it containing a virus is very, very low.  However, the reason why the lawyers of XYZ Company told their marketing department to include that disclaimer is because of control.  More specifically, it is because of the lack of control.  Once that CD leaves the door of the vendor they don’t know where it could go and through how many hands it will pass.  It is highly unlikely that they burned the CD themselves either.  They will have used a service provider that stamps out CD’s with the label by the hundreds at low cost.  Again, another point of loss of control that keeps the lawyers up at night.

However, with a Xuropa Online Lab you not only have complete control over the environment and who uses it, you also don’t have to go to the wasted expense of sending out hundreds and thousands of CD’s to people that have no interest in the product at all.  (Not a very green approach either.)

So in summary, the cloud is extremely secure.  It is in everybody’s best interest to make it even more secure.  For those malcontents with too much time on their hands life will actually get more limited with a move to the cloud.

You can reduce your overall marketing costs, decrease your “carbon footprint”, and let your lawyers sleep easier by moving to the cloud.

Keep control and keep lawyer fees to a minimum - not a bad thought going into the new year.

Click here to register for the Xuropa Online Electronic Design Community

Posted under Features, Xuropa, business, industry, marketing

Already the web is alight with the chatter of the new browser from Google announced yesterday - Chrome.  There are a few things that bother me about this though.  The most important are productivity and the user experience.  Both of which come down to the same thing - standards.

Long ago, we in the electronic design industry learned the many advantages of creating, implementing and supporting standards. We realized that the point at which different products intersect is not where the value resides.  In addition, to make this point in the system standard increases “ecosystem” productivity and ultimately the value of the entire system.  Everybody wins.

In the world of web-based system and application development a great deal of productivity is wasted in building and testing software to execute to specification within the two leading browsers IE (our least favorite) and FireFox.  While competition is a good thing, and maybe we needed another 800lb gorrilla in the room to bring all of the standards together, to release a product that is beta 0.2 (!!!!) through a channel as powerful as Google’s is irresponsible.

To bring the security (already an issue discovered with Chrome), compatibility and user experience overhead to the web when Google has the resources to bring the industry quality and increased productivity is again irresponsible.

Google needs to take a stronger leadership position and start being “the adult in the room”.  They have the resources, the leverage and the war chest to deliver a product that can do that - they don’t need a 0.2 beta to “gain traction in the marketplace”.

Posted under industry