Article reproduced courtesy Mark Cresswell Scalable Software.

An increasing number of vendors (including Scalable) are offering elements of the IT Asset Management stack that are deployed inside public cloud environments. These include IT Service Management, Software License Management systems, Network Discovery and Inventory, IT Asset Tracking and others. The deployment of ITAM in the cloud represents a perfect storm of reasons for security concerns to surface. The fundamental question of data privacy always emerges in the context of SaaS, but where ITAM in the cloud is concerned this is compounded by the nature of the data. Specifically, ITAM data can contain information about IT systems that in the wrong hands could weaken an organizations defense against hacking. Information relating to internal network layouts; the location of critical systems; connections to the broader internet; patch levels for key machines and many other similar items are best kept away from blackhat hackers.

For many organizations these facts are enough to move cloud-based ITAM off the planning sheets; there are no counter-arguments that would overcome a visceral initial reaction to the risk profile outlined above.

However, if implemented correctly, ITAM in the cloud is not only a highly secure proposition, it also enables benefits that are simply not possible for traditional on-premise tools. If you have an open mind about security of cloud-based tools what follows will hopefully serve as a useful primer in the debate.

Discovery Credentials – Most organizations lock down access to the protocols often used for discovery in such a way that only network admins can run them. Although credentials can be securely maintained in cloud databases, it is important to enable discovery to run without that requirement. Stated differently there should be an option to ensure that discovery credentials never leave the organizational security perimeter.

Data Encryption/Protection At Rest – obviously the database maintained by the system must be encrypted. However, the encryption key must be unique to the customer and not available outside of the customer application instance. Stated differently, were the database itself to fall into the wrong hands it would be useless. Unless the key itself was compromised, the only way to read the data should be through the application.

Data Encryption/Protection in Transit – similarly data in transit between the assets being managed and the instance of the SaaS environment must be encrypted.

Data Sovereignty – a consideration with SaaS implementation is who has legal jurisdiction over the data. Laws exist in most regimes that give law enforcement agencies rights to access data that is resident within their borders under certain circumstances. Determining where the data physically resides may be important in the context of your business.

Perimeter Security  – In this context I am referring to the technologies that prevent both Denial of Service (DoS) attacks and unauthorized system penetration by means other than the application (which is addresses by strong identity management and authentication). The SaaS provider itself must be able to verify that it has application layer and system layer firewall protection that will ensure that only authorized sessions can be established with the application layer. Furthermore the provider of the compute resources or Infrastructure as a Service (IaaS), which the application consumes, must be able to demonstrate that each machine image is protected from penetration and that the subnet the SaaS provider inhabits is further protected. IaaS providers such as Amazon EC2 go to great lengths to verify the latter aspect of this protection through independent assessment.  Denial of service (DoS) attacks are probably the area where the gap between SaaS tools and on-premise tools is the greatest. Since on-premise tools benefit from an organizations perimeter protection that prevents external access to internal tools, DoS attacks are virtually impossible. In the case of SaaS tools, at the very least login pages can be reached by anyone that is aware of a login URL. DoS attacks include such things as Main in the Middle (of which a variety of forms exist, and network saturation. The methods available to mitigate such attacks is a book unto itself and way beyond the scope of this post, however good SaaS and IaaS providers will have much to say when questioned on the topic, and it is certainly one worthy of extended discussion given the variety of approaches available.

Physical Security – As in all datacenters, physical security is an important consideration. The IaaS provider used by the SaaS vendor, should be able demonstrate robust physical security practices. Again, the larger IaaS providers have this process well documented and supported. Some SaaS vendors maintain their own hardware infrastructure, which doubles the burden of security, but it does mean the buck stops at just one door.

Identity Management – Managing and authenticating the users of the system is critical, and an area of great concern.  At no point in the process of provisioning a system should a user receive any communication that contains a password; this is a gigantic red-flag since it implies the password is either stored in clear or maintained using a symmetric encryption method. The SaaS vendor should have no access rights to the systems or the data, unless the customer explicitly grants those rights; neither should the vendor maintain an emergency back-door. All password-reset processes should be self-service. The customer should be able to see details of all system access and be solely responsible for granting such access – including standard role-based access rights.

Two-Factor Authentication – Simple userid/password combinations are simply not good enough for a variety of reasons beyond the scope of this post. Two-factor authentication, where either a device token or a unique, one-time ‘passticket’ is combined with a userid and password, has emerged as a way to dramatically strengthen the authentication process for SaaS applications.  Examples of this in action include the receipt of an SMS or email, with an alpha- numeric sequence, that must be entered alongside the userid and password within a certain amount of time after receipt; or the addition of a security token, which is stored on the endpoint device, to ensure that an authorized user can only access the system from an authorized device.

Mutual Handshaking – ITAM tools, which exist in the cloud, require an application proxy of some sort that exists behind the corporate firewall in order to perform network discovery, software inventory, and to integrate with procurement systems, service desks etc. The setup of this proxy is core to the security discussion as it is the pipe down which internal asset data flows. The proxy must not require non-standard corporate firewall behavior. The proxy must be the end of the connection that initiates the session and it must do so via whatever security polices are in place, such as a network proxy. The proxy must ‘know’ which SaaS application instance to connect to and should not support in any way configuration that would enable it to connect to a different instance. I.e. it is conceptually just an extension of an individual SaaS instance. The SaaS instance should be similarly constrained; it must not allow connections from application proxies spawned by other customer’s instances of the SaaS application.

Backup/Recovery – Backup and recovery systems are well-understood by most buyers of SaaS systems, so the point need not be elaborated other then to ensure that claimed recovery times should be verified. Many of the IaaS providers have hot standby and image reload capabilities built into the service they offer their SaaS customers. These systems are sophisticated and may not be present where a SaaS provider maintains its infrastructure.

Hardened Operating Environment – Hardening the operating environment is a generic term for a range of measures designed to close vulnerabilities in the operating system, and associated subsystems, that exist as a consequence of maintaining configuration flexibility. Any SaaS vendor with a well-architected system will have hardened their environment, but if you can establish this is not the case then some serious questions must be asked. A well-hardened operating environment will prevent password-based SSH logins for admins; stop unnecessary services from running; close all unnecessary ports at the OS level; implement AppArmor to ensure applications access only those systems resources to which they have been explicitly granted rights; encryption of the operating environment logical volume etc etc. The full list of hardening tactics is long and arcane, but represents a fundamental level of threat protection a good SaaS system cannot be without

Independent Verification – Regardless of the claims made by the SaaS or IaaS vendor, independent verification is vital. Well-managed organizations such as The Cloud Industry Forum and The Cloud Security Alliance have emerged to satisfy this need. In addition the AICPA has set out SAS 70 as benchmark for control procedures of service providers. The Type II extensions for SAS 70 can be applied to both SaaS and IaaS vendors that wish to demonstrate the strength of their Systems Development Lifecycle (SDLC), intrusion detection systems (both physical and virtual) and other operation controls.

A question folks evaluating SaaS tools really need to get to grips with is whether their own organizations can claim strong support for the items listed here. The reality is that most (not all, but the good ones can demonstrate independent verification) SaaS and cloud infrastructure providers have realized that being fanatical about security is the only way they can prevail. Another way of looking at this point is that security is a fundamental element of the business of a SaaS provider in the same way that airplane maintenance is fundamental to an airline. Where a discipline is so central to a business model it tends to get taken very seriously.