In today’s blog, I wanted to touch on how a made-to-order manufacturer finally decided to commit to moving their ERP to the cloud after a black swan event that has shaken up the organization. This was a tip-off that we received from one of the Cloud ERP vendors that we partner with.

So – how is this manufacturer currently managing the many complex and distributed ways its business is running?

With pen and paper. Seriously. Good old-fashioned pen. And paper.

Could have, should have, gone with SaaS

Here’s the backstory. The manufacturer’s previous on-premise ERP system had been hacked, which disrupted its ability to function and exposed its business to significant risks. To add insult to injury, the hacker or hackers encrypted all of the compromised files and data, effectively locking the manufacturer out of them.

With no other means to continue operations, the company has had to resort to the technologically primitive stopgap measure of taking orders, managing manufacturing, and ensuring fulfillment with paper forms – and lots of legwork, calls, and faxing.

Starting over with SaaS

At the same time, its team has had to rebuild. So they are now reviewing a new SaaS ERP solution because in their minds, not only would this mean less work for their IT people, it would even be more SECURE than their previous on-premise set up.

And while they are planning a cloud ERP system from the ground up, they are also taking the opportunity to load up on a few extras.

On top of the accounting package with BOM, inventory control, OE, Purchase Order and payroll modules, they are also planning for future upgrades such as bar code functionality and serial number allocation to the BOM to minimize errors, as well as a way to create RFQ’s in the purchasing module that would convert the RFQ into a new PO.

Conclusion – Changing Views of Security

Perceptions around security and Cloud ERP and SaaS have come a long way. Four years ago, security perceptions were the number one reason that customers elected not to go to the Cloud. In a 2010 Aberdeen research survey, the desire to control upgrades surpassed security as the number one concern for ERP buyers. As more articles on cloud ERP security are published, customers are overcoming inaccurate perceptions of security. Advice to companies with on-premise servers – perhaps it might not be a bad idea to start planning for a transition to a Cloud ERP solution before a black swan comes a-calling!

Despite the progress, many businesses still have security concerns when it comes to the Cloud. This article addresses security issues that are specific to enterprise resource planning in the cloud.

Cloud ERP Security Topics

Just like a traditional on-premise ERP solution, Cloud ERP must provide physical security, transmission security, storage security, access security, data security, and application security. We will use these broad classifications for discussing the similarities and differences between Cloud ERP and traditional ERP software security.

Physical Security

Even a cloud application and data must be located somewhere. The physical surroundings of the software and data is an important component of a business continuity plan as well as a software security plan. A physical security breach means that somebody with malicious intent has physical access to the hardware where either your application is running or where your data is stored.

If other forms of security are in place, a physical security breach will not result in loss of data. However if the intruder’s intent is to disrupt your service, then a lapse in physical security will be a problem. Part of your business continuity plan should include a solid physical security plan.

Cloud Differences: when applications and data run in an external cloud, the physical environment is located off-premise. In most cases physical security in a tier 1 datacenter is many times better than that in an office building or an internally run server room. All building access is logged, cameras are in place, and cleaning people are not generally milling about after hours. State of the art authentication technology (fingerprint, ID badge, retina scans) are often implemented.

SaaS applications are run by administrators who are employed by the software vendor or cloud provider and not the company who purchased the ERP software. The quality and reliability of administrators depends more on the resources and focus than the employer.

Transmission Security

When data is communicated between the user, the server, and the database, there is a chance that transmissions can be intercepted. An easy way to prevent this involves encrypting all communications between source and destination. However, encryption comes at a cost to performance. If you spend too many processing cycles encrypting and decrypting data, you will have to purchase more expensive hardware or endure delays.

There are several types of security algorithms that are used to protect communications. The underlying idea is that sensitive or private data is scrambled using an encryption key and a data encryption algorithm. The data cannot be read or deciphered without the decryption key. The decryption key can be the same (symmetric) or different (asymmetric) from the encryption key. Once scrambled, the data is sent to its destination. If intercepted, the data can only be reconstructed by using an algorithm that tries to guess the description key – a process that takes many years using powerful computers. When the scrambled data arrives at its destination, the receiving party knows the proper decryption key by querying a key master or certificate authority. Several common algorithms include RSA, Secure Socket Layer (SSL), Data Encryption Standard (DES), Triple DES. An explanation of these algorithms is beyond the scope of this post but is well documented elsewhere. An example of SSL encryption processes most commonly used by Cloud ERP vendors is provided in Wikipedia.

Cloud Differences: applications running in an external cloud require passing data between the cloud and the user location. Frequently this occurs over the Internet and over wireless networks. Furthermore, client machines are mobile (access from anywhere being a big advantage of the cloud) so processing power and bandwidth may be at a premium. Web-based systems utilize a browser on the client device and take advantage of SSL encryption to protect all communications with the server. The SSL algorithm is supported by all major browsers and encapsulates application-specific protocols like HTTP to form HTTPS so no one can hijack a session or read the data. SSL requires negligible computing overhead and is acceptable security for banking, health care, and other sensitive industries.

Some folks ask about SOAP and how that differs from HTTPS. HTTPS helps you communicate between browsers and servers, but SOAP provides secure communications between applications. SOAP encapsulates additional data in the form of XML so cloud applications can communicate more efficiently than if they were required to send a series HTTP requests.

Storage Security

When ERP data is accessed by users, business logic limits unauthorized access to users with the proper credentials (see section on application security). But suppose a network administrator has access directly to data in the database. In this case, the data could be viewed without going through the business logic.

To protect against this vulnerability, sensitive data should be encrypted when it rests in the database or in a file system. This prevents direct access and ensures that all data is only accessed via the application logic. The application knows how to decrypt the data, so a legitimate user will not be impacted.

As with transmission security, the encryption and decryption processes create processing overhead, so non-sensitive data should be stored in the clear to minimize costs. Additionally, make sure that any required data indexing is not broken in the encryption process.

Cloud Differences: In cloud systems, data is stored in a remote location on servers maintained by a cloud provider. The cloud provider should have procedures in place to ensure that there is no direct snooping into client data. But somebody has to be responsible for database administration, and usually this person is not employed by the client. The ability to pick and choose fields to encrypt on the database is important to provide protection without adversely impacting performance.

Access Security

Access (or perimeter) security is important for preventing unwanted users from grabbing resources and sending unauthorized queries to your servers. Usually this is accomplished through the use of firewalls that prevent unwanted traffic from communicating with your business applications. Lack of access security could impact your application availability (in the case of a denial of service attack) and provide hackers with a way in to make it easier to steal resources or passwords.

There are many types of firewalls … network level firewalls (fast inspection of IP, port, and service in the packet headers), circuit level firewalls (monitor sessions between computers), application level firewalls (inspect data content to protect against viruses and intruders), network address translation devices (NAT – assigns private IP addresses that cannot be reached from outside the network), and proxy servers (application level firewall that mediates transactions between computers).

Network and circuit level firewalls can be implemented in an appliance or as software. Application level firewalls are most frequently implemented as software to allow for specific configuration requirements.

Additional details of perimeter security devices are well documented elsewhere.

Cloud Differences: Cloud systems should be protected by perimeter security – just as you would protect any on-premise application. Verify that your cloud provider has firewall protection in place to prevent intruders and denial of service attacks. Multi-tenant cloud applications is slightly different because by definition, multiple users are accessing the same application code and the same resources. In this case, processes must be in place to ensure that bad things do not happen to customer A if customer B’s application is compromised.

Data Security

Data security limits access to data objects to specific individuals. Different levels of data security include read-only, edit, insert, and delete. Data security can be set at the application or object level.

Data security for ERP systems may be enforced through business logic or at the database layer. In most cases the business logic authenticates users and provides them with specific rights to data objects. This means that authenticated users gain access to objects based on specific capabilities assigned by the system. For example, a sales person may have read-only access to product information so he cannot change the pricing/margins/commissions associated with the product. A sales person may have access to customer records that he manages, but not have access to customers managed by others. To simplify management, systems offer role-based security so administrators can assign broad security policies to specific individuals. Accounting, marketing, sales, shipping, and management roles can be established and assigned to individual employees. Employees that perform more than one role can receive multiple policies. By assigning roles, administrators can change security for many people at once without the responsibility of changing individual records.

Most data security is limited to data access. Once a user gains access to specific information, screens, or reports, the information can be downloaded and shared with others. Digital rights management goes one step farther by “wrapping” data objects with rights that follow the object no matter where it goes. In this case, users can forward the encrypted data, but that data cannot be viewed or changed unless the recipient can be verified.

Cloud Differences: Data security in cloud applications is similar to traditional applications. Once individuals gain access to the system, the business logic controls the specific capabilities that individual users can perform on different objects. In some types of multi-tenant SaaS applications, database level security may be utilized as an additional measure to separate data objects from different companies.

Application Security

Application security encompasses two major areas – the way the application authenticates and manages users and the way in which application code is managed.

User Authentication

User authentication usually involves username and password to identify legitimate users. User identity is critical not only for establishing data rights, but also for creating an audit trail of activities for compliance purposes. Modern systems require strong passwords, enforce lock-out from excessive failures, and give administrators the option to require users to change their password on specific time intervals. In addition to these common security measures, administrators may restrict access to the system by IP address to combat hackers that try to guess usernames and passwords from remote locations.

Borrowed or stolen passwords can circumvent the most sophisticated technologies, so administrators may require two-factor authentication through the use of security tokens. Augmenting passwords with key fobs that generate time limited passwords provides physical access control from anywhere at a very reasonable cost. Secondary, one-time passwords can also be sent to a mobile phone via SMS. Products include SecurID from RSA and many others.

Authenticated users are granted access to specific data and processes. The ERP application must provide security measures to prevent authenticated users from doing unauthorized tasks. For example, somebody authorized to input data should not be able to delete data. If somebody is authorized to fill out a form, the data must be examined to prevent overflow and SQL injection issues.

Managing Code and Logic

All ERP software undergoes revisions and updates. The processes that manage these updates can be included as part of the overall security plan provided by the vendor. For example, when compiling the final code, processes are in place to insure that rogue code is not inserted into a production build.

Cloud Differences: A major benefit of the cloud is the ability to run your business from anywhere on any browser. In client-server environments that sit behind firewalls, clients are often “trusted” machines. To equal this level of security, cloud systems require all business logic to run on the server and consider all clients as untrusted. By enforcing all business logic at the server, cloud systems are actually more secure that client-server systems that rely on files and components installed on user machines.

When purchased as a service, application upgrades and updates are outsourced to IT professionals. Make sure that the external processes and controls in place are satisfactory for your security and business continuity needs. SSAE16 recently replaced SAS70 as a third party testament that the system of software and controls in place were acceptable on the date of certification. More about SSAE16 here. Finally, make sure you understand when upgrades occur and if those changes will be acceptable to you.

Summary and Conclusion

Cloud ERP and traditional ERP share many of the same security issues. In the case of traditional ERP, security issues are managed by internal IT resources. In the case of Cloud ERP, similar issues are managed by external resources. A third party audit can be done to certify that external processes are documented and followed – but in most cases, the vendors pay more attention to these details than internal resources would.

In a cloud deployment with shared hardware, a shared operating system, and customer-specific application code, the security issues are almost identical to traditional ERP. Distances covered by transmission security are longer, but that has little impact on overall security. When the cloud is running a multi-tenant application, the data security and application issues are slightly different, but not necessarily less secure. In a multi-tenant deployment, the application must be designed to prevent client 1 seeing client 2′s data. As far as I know, all Cloud applications are designed in this way. The multi-tenant application must also allocate resources so client 1 cannot steal resources from client 2 during a period of heavy usage.

When using a web-based cloud application, client software is replaced by a browser. From a security perspective this usually has little impact because in a well written cloud application, all application security is performed on the server. The client software is inherently not trusted.

Conclusion: cloud ERP and cloud ERP data are as secure as traditional on-premise ERP systems. Some of the security issues are different and perhaps less familiar, but once understood, many experts conclude that cloud systems are more secure than poorly run internal applications.

Recently, we spotted a discussion on Dennis Howlett’s blog where he reports a discussion with Vinnie Mirchandani:

“In a back channel discussion with Vinnie Mirchandani, he said that NetSuite’s Zach Nelson saw the recession coming way before the headlines started to dominate the general news. How? Because NetSuite manages the data for more than 6,000 companies and he could tell by observing activity levels how customers’ business was trending.”

Mr. Mirchandani gathered this information in an interview for his upcoming book “The New Polymath” which will be available in June.

According to some, using this information in aggregate is completely acceptable. In other words, if your ordering and sales activities drop, you and your SaaS provider will be the first to know.

Hopefully your SaaS provider isn’t tempted to dig further into your activities as they search for ancillary sources of revenue. Wall Street firms, analyst firms, and others are willing to pay big money for these leading indicators.

Should you worry?

No, but you should be diligent. Presumably NetSuite and other SaaS providers have procedures in place to guarantee that your data is not available to them in any shape or form. If “activities levels” are required for billing, then obviously this data will be available, but it’s up to your SaaS provider to control how that information can be used.

Forrester Research cautions companies considering using cloud-based services to gain a clear understanding of the security privacy and legal consequences before contracting with any service provider. Read More.

You should make sure that you have full audit rights to all activities that are performed with your individual data records as well as your aggregate data. You need to make sure that you do not run afoul of something like Sarbanes-Oxley because your SaaS provider is monitoring your inbound and outbound communications. Compare your organization’s risk management and compliance priorities those of your SaaS provider.

Can SaaS providers be hacked?

Odds are that your SaaS provider will have better procedures in place and more security expertise than you can provide internally. But, your SaaS provider will also provide a bigger target as witnessed by some of the recent mishaps with security at Google.

As proponents of “ERP cloud” we defend the notion of using SaaS and cloud computing, but caution that proper management and perhaps an internal cloud option is required. With an “internal cloud” you are in control of your own datacenter and processes, however, this can be more expensive than outsourcing to a provider with hardware, management personnel, and processes already in place.

The SaaS standards Dream

Customers can purchase SaaS applications which share information through a group of standards (this reminds me of some web federation attempts). This eliminates several problems associated with sharing data across different SaaS applications, so, your ERP application can talk to your CRM application – even if both were provided by different vendors.

The SaaS standards Nightmare

Security requirements and bandwidth fees could interfere with the smooth flow of data. In his article, Dennis mentions international data domain issues (especially in the EU) that require international collaboration and planning. In addition, assume that your SaaS provider charges for incoming and outgoing data … in that case, things could get troublesome if too much data is constantly being swapped.

Not Mentioned (and critical)

Although not mentioned in the article, the same set of SaaS standards could also apply to SaaS applications run on internal clouds. Without standards, customers have to purchase applications from a single provider or use a proprietary platform to interface with that provider. With standards, customers could buy some applications as SaaS and run others internally. Further, customers could use those standards to retrieve their data at any point in time. This would avoid potential vendor lock-in issues that slow the adoption of SaaS.

Today’s Solution

The finalization of standards and subsequent adoption of those standards by a large number of vendors could take quite a few years. Prior to that time, customers can purchase applications developed with standard development tools which have the flexibility to be run on-premise or as SaaS. Then, integration with line of business applications can be done easily using APIs and customers do not have to be concerned with lock-in issues.

SaaS can be a huge benefit, although standards would be great – don’t wait for them, get started today.