Author Archives: shallem

REvil has struck again. What can we do? Design for explicit access.

Posted on by
1

At a glance… 

  • Kaseya VSA is used by IT organizations and many Managed Service Providers (MSPs) to track IT assets and to deliver software installations and patches to a network of endpoint nodes.  
  • Over the 4th of July weekend, a ransomware attack perpetrated by the REvil gang and its affiliates was delivered through the Kaseya VSA remote management software.  
  • Each Windows node on the network runs a Kaseya agent, which is responsible for downloading and installing patches and software packages from the VSA server. It is common practice for an MSP to use a single VSA server to manage all of the MSP’s client networks, meaning that one compromised VSA server can create a downstream impact on hundreds of individual businesses. 
  • 1,500 businesses may be effected. 

The fascinating anatomy of the hack 

REvil’s successful hack began with an SQL injection attack against the VSA server. The attacked VSA servers were exposed to the Internet, presumably to allow for remote access to the VSA server by an MSP’s employees. An SQL injection attack was crafted by the hackers to (a) bypass authentication, (b) upload a file, and (c) inject a command to distribute a malicious software patch. This software patch was then dutifully downloaded by Kaseya agents installed on Windows endpoints attached to the compromised VSA server. The technical details of how this was accomplished are explained quite clearly in this article by Sophos. 

The hack itself is fascinating from a technical perspective in multiple ways. First, an authentication bypass renders an entire stack of security technology (authentication providers and MFA) entirely irrelevant. There is no password guessing or credential stealing involved in this attack. Second, the MSP model where client networks are intermingled in a single VSA instance is inherently dangerous in that a single compromised server (whether it be a via a 0-day exploit or a more traditional stolen credential) can spread malicious software across many disparate organizations, geographies, and networks. Third, it is perturbing that a piece of software like the VSA server was directly exposed to the Internet. The lack of any intervening, independent authentication (e.g., a VPN or IIS authentication using certificates or Kerberos) places an inordinate amount of trust in the security architecture of a single piece of software (the VSA server). 

In general, the best way to mitigate hacks of all varieties is to apply a few principles: 

  1. Keep independent networks as separate as possible, and always require authentication to move between them. 
  1. Authenticate users and devices in layers that rely on disparate software stacks. Software is built by humans, and humans make mistakes that cause security vulnerabilities. Using independent software stacks to layer together multiple forms of authentication ensures that a hacker has to find multiple, independent mistakes that are exploitable in conjunction. 
  1. Because there is still no perfect way to prevent endpoint attacks from happening, effective endpoint protection is essential. The Kaseya exploit relied on anti-virus exceptions on the endpoint to allow a malicious file to be downloaded, decoded into an executable, and run via a shell command. This malicious executable then executed a side loading attack to actually launch the encryption process. Effective anomaly detection could have shut down the encrypting process before it got too far, and an alternative approach to using an anti-virus exception would have stopped the attack when it tried to execute the downloaded executable. 

A collective reconsideration of how we protect networks and endpoints is overdue 

This latest attack from REvil confirms the obvious – the business of ransomware is here to stay. Whether it is REvil, a spinoff from REvil, or an entirely new organization that is inspired by REvil’s success, a collective reconsideration of how we protect networks and endpoints is overdue. It has become standard practice to disable security software in order to enable functionality, rather than demanding the opposite – that software declare its intended behaviors in order to enable security software to detect anomalous behavior. 

A system of specific access vs. access to the entire network 

Our LINK system is architected with this last principle in mind. Rather than assume that all mobile devices need access to the company network (e.g., via VPN), LINK assumes that only a small number of applications and data repositories should be mobilized. To configure LINK, IT specifies exactly what intranet applications, email servers, and file repositories (Document Management Systems, One Drive, SMB shares, etc.) should be accessible from a mobile device, and this specification is role-based so that IT can take a pessimistic approach to mobile access (i.e., you can’t access anything unless permission is explicitly granted to you). LINK also uses multiple, independent layers of authentication – SSL certificates to authenticate the device, then traditional password-based authentication if the SSL authentication succeeds. Finally, each LINK installation acts as its own certificate authority for the purposes of SSL authentication. Hence, stealing a certificate for one installation does not grant access to any other installations. 

As we expand LINK beyond mobile, our goal is to promote a different approach to endpoint computing. This approach starts with the idea that users, applications and data need to be integrated explicitly, rather than implicitly. This creates a work environment that is easily encapsulated, encrypted, and protected with limited entry points and exit points to move data in and out of this environment. While no approach is perfect, the more explicit we are about how users, applications, and data interact, the better chance we have to stop the ransomware business before it expands any further. 

-Seth Hallem, CEO & Co-founder, Mobile Helix

Research Reveals iOS and Android Encryption Weaknesses

Posted on by
Reply

Why Secure Containers Are Needed

The Research

iOS has solid encryption, there is no backdoor, hence, your firm’s data is safe under lock and key, correct?  Not necessarily. Enlightening new research by cryptographers at Johns Hopkins University (1) has surfaced weaknesses in the iOS and Android encryption schemes. Ironically, in the case of iOS, part of the weakness is related to a security hierarchy which is often unused.

“Apple provides interfaces to enable encryption in both first-party and third-party software, using the iOS Data Protection API. Within this package, Apple specifies several encryption “protection classes” that application developers can select when creating new data files and objects. These classes allow developers to specify the security properties of each piece of encrypted data, including whether the keys corresponding to that data will be evicted from memory after the phone is locked (“Complete Protection” or CP) or shut down (“After First Unlock” or AFU) …

… the selection of protection class makes an enormous practical difference in the security afforded by Apple’s file encryption. Since in practice, users reboot their phones only rarely, many phones are routinely carried in a locked-but-authenticated state (AFU). This means that for protection classes other than CP, decryption keys remain available in the device’s memory. Analysis of forensic tools shows that to an attacker who obtains a phone in this state, encryption provides only a modest additional protection over the software security and authentication measures described above.” (JHU – bold is our addition)

The reality is that most of our iPhones are commonly in “After First Unlock” state because we rarely reboot our phones. To achieve maximum security, we would have to power down our iPhones and authenticate after each use. That is, scores or hundreds of times per day. Otherwise, all data in the AFU state is vulnerable to law enforcement agencies or criminals with the right forensic tools. As the Hopkins researchers noted, “Law enforcement agencies, including local departments, can unlock devices with Advanced Services for as cheap as $2,000 USD per phone, and even less in bulk, and commonly do so.”

“There’s great crypto available, but it’s not necessarily in use all the time,” says Maximilian Zinkus, Johns Hopkins University. The Hopkins researchers also extended their analysis to include the vulnerability of iCloud services and device backups:

In an interview, Apple stressed that its goal is to balance security and convenience. The result: law firms and other enterprises who rely on iOS’ first-party apps (e.g., iOS Mail) may be unknowingly using an encryption scheme which does not meet their requirements.

Device owners may take actions to ensure greater security. Apple Insider cites a few user actions including: Use SOS mode; use the setting which locks iOS devices after 10 failed login attempts; and don’t use iCloud back-ups. But these user-optional mitigations are not adequate for enterprise security, and they don’t address the forensic techniques used to steal data in the AFU state. Enterprises need systematic approaches across all firm-managed devices.

Why Secure Containers Are Needed

Sophisticated attackers and government agencies have a variety of available tools at their disposable to extract sensitive data from a seized or stolen device. The preponderance of evidence shows that law enforcement is largely successful in cracking open a device and extracting sensitive information as needed. Evidence further suggests that these techniques are ported to even the latest iOS versions and devices (take a close look at https://www.grayshift.com/ – they offer the state-of-the-art in device forensics). What can you do to truly protect sensitive data? The built-in capabilities of the operating system are not sufficient.

Secure containers provide an additional layer of encryption by implementing an entirely independent encryption mechanism to protect data. To examine the protection offered by secure contain apps, we will refer to our LINK app in this discussion. LINK not only uses its own, independent encryption scheme, Link also uses its own built-in encryption technology. In other words, the LINK encryption software stands entirely independent from the operating system, regardless of whether that operating system is intact or compromised. As long as encryption keys are protected well, then secure containers can provide the kind of locked-down encryption that law firms want to protect email and documents, which encapsulate a large majority of a firm’s most sensitive data.

LINK’s data protection exceeds iOS in a few significant ways:

  1. LINK is an app, and iOS apps are routinely removed from memory. Hence, while LINK does necessarily keep encryption keys in memory when the app is active, once the app is removed from memory its encryption keys are too. This stands in contrast to iOS’ “AFU” encryption.
  2. LINK allows IT to identify data that is only accessible when the device is online. This makes it awfully difficult to get the encryption keys for that data, especially once the device has been identified as lost or stolen and flagged for a remote wipe.
  3. LINK’s online encryption keys are really hard to guess. Offline keys are hard to guess too, as long as your organization uses complex A-D passwords. Online keys are not derived from a user’s passcode or even a user’s A-D password. LINK’s encryption keys are derived from randomized 32-character strings that are generated on the LINK servers using entropy available on the server. Brute-forcing the key derivation is unlikely to work, which means an attacker would have to compromise the LINK Controller that sits safely inside our customers’ networks, then break the encryption scheme protecting sensitive data stored in our Controller database. Getting LINK data is a lot more complicated than stealing or seizing a mobile device.
  4. LINK aggressively limits the amount of data available on the device, online or offline. We do so by simply expiring away data that sits unused on the device. This is a really simple way to limit exposure without much practical impact on a user. Users can always go back to their email (via search) or to the document management system to find what they were working on. There is no practical reason to store lots of old, unused data on a device that is easy to steal and, as it turns out, compromise once stolen.
  5. LINK’s data is useless when obtained from an iCloud backup or a local backup to a Mac device. LINK’s encryption keys are never backed up. An attacker’s best hope is to brute force both the iOS device passcode and the user’s A-D password before IT notices that the device is lost or stolen. This is incredibly difficult to accomplish given Apple’s built-in protections against brute-forcing passcode and given a reasonably complex, hard-to-guess A-D password.

The JHU research simply reminds us that Apple’s interests diverge widely from those of an individual law firm. Apple has to balance the needs of law enforcement and users to make data accessible while still providing a reasonable degree of protection. Law firms’ best interests lie in maximally protecting data against unauthorized access. In order to achieve this latter goal, Apple’s built-in technology simply won’t suffice.

-Seth Hallem

Seth Hallem is the CEO, Chief Architect, and Co-Founder of Mobile Helix, makers of the LINK App. With LINK professionals can review, annotate, compare, and email files, as well as use the firm intranet, using a single secure container app. www.mobilehelix.com

References:

  1. “Data Security on Mobile Devices,” Maximilian Zinkus, Tushar M. Jois, and Matthew Green, Johns Hopkins University.
  2. “How Law Enforcement Gets Around Your Smartphone’s Encryption,” Lily Hay Newman, Wired.
  3. “Many iOS Encryption Measures ‘Unused,” Say Cryptogographers,” Hartley Charlton, MacRumors.
  4. “Apple encryption is a balance between user convenience and total security, new study shows,” Wesley Hilliard, AppleInsider.

Our CEO in CSO: Ripped from the headlines – are your messages secure in these encrypted apps?

Posted on by
Reply

In the investigations of Paul Manafort and Michael Cohen, the FBI has retrieved messages from Signal, Telegram and WhatsApp. While there are weaknesses inherent in all of these apps, the question remains: What does a good data protection scheme look like?

 

A few days ago, the FBI revealed that Michael Cohen’s messages sent with Signal and WhatsApp are now available as evidence in the on-going investigation into his various dealings. While thousands of emails and documents have already been recovered from Cohen’s devices, home, hotel room, and office, the recovery of data from messaging apps that promise end-to-end encryption is surprising. One would presume that end-to-end message encryption should ensure that those messages are unrecoverable without assistance from Mr. Cohen. However, clearly that is not the case.

Continue reading →

AI? What about NI? Enhancing Natural Intelligence Makes Better Lawyers

Posted on by
Reply

By Mobile Helix CEO & Co-founder, Seth Hallem in Legal IT Professionals

Seth HallemA good lawyer helps you see around the bend. In my experience over the years as a client, I have found that each time my attorney points out something in a contract or business decision that I had not anticipated, I ignore the next bill when it comes in and I pay it gladly. When I feel that my attorney is simply a contract factory, I look at each bill closely and start to wonder if there is a better way.

I recently had this experience with my company’s attorney and, as has become my custom, I did not pay any attention to the forthcoming invoice. I did, however, stop to think about how my company, as a legal technology provider, could facilitate more such interactions for our customers and their clients.

Bend fog tyler-lastovich-371909-unsplash.jpg

A few months ago, I read an article summarizing a survey conducted by Clio. The headline of this survey is that lawyers bill only 2.3 of every 8 working hours, instead spending the plurality of their day on administrative tasks. This article jogged my memory of another article from the American Psychological Association (APA) that outlined the significant productivity lost due to context switching and distractions. If my attorney is to be a source of insight, he or she cannot be compromised by distractions that lessen her effectiveness.

Continue reading →

Hacking is a booming business, and it’s time for a disruption – CSO Online

Posted on by
Reply

By Mobile Helix CEO and Co-founder, Seth Hallem

Hackers are siphoning billions from the global economy each year by stealing data for profit. However, in spite of this rising threat, enterprises continue to make the same mistakes over and over again. It is time to change our assumptions and to re-think how we protect sensitive data.

Hacking is a booming business. Business has been good for several years now. Data breaches are at all-time highs. Cyber-attacks are skyrocketing, and ransomware is a growing fad. And the best news of all is that the same old tricks (see XSS, SQL Injection, SPAM ….) are still working just as well as they always have. How is it possible that a business that was estimated to cost the global economy $450 billion dollars is continuing to grow? That is a lot of money diverted to criminals in lieu of legitimate participants in our global economy.

Continue reading →

What CISOs must learn from Bitcoin and a research team at Georgia Tech

Posted on by
Reply

By Seth Hallem, originally published in HelpNetSecurity, Sept. 16, 2013

It has been an eventful time in the mobile world with two recent breaking stories revealing vulnerabilities in the security infrastructure for Android and iOS respectively. While vastly different in their nature, both point to a fundamental lesson that CISOs in an increasingly mobile world cannot ignore – when it comes to encryption, read the fine print. Otherwise you may find yourself up the proverbial creek without a paddle (i.e., remediation strategy).

Continue reading →

In the aftermath of yet another Meltdown, no secrets are safe – Seth Hallem

Posted on by
Reply

Meltdown and Spectre reveal that perfect information protection comes at an increasingly steep cost.

In the field of data security, 2018 began with a jolt. The revelation of the Meltdown and Spectre security vulnerabilities has taught us that in 2018 (and beyond), nothing is sacred.

Speculative execution, the architectural concept that is exploited in the Spectre vulnerability, has been in use by mainframe processors since the mid-1970s. It is taught in Computer Architecture 101 in universities around the world. And yet, it turns out that the security implications were never fully understood until about seven months ago.

Out-of-order execution, the culprit in the Meltdown vulnerability, is also a ubiquitous concept, although Meltdown is easily avoided with a better implementation of the concept.

Continue reading →

Who can you trust in a BYOX world?

Posted on by
Reply

Apple has long held the reputation as the most trusted device vendor in the new BYOX World. iPhones and iPads are the devices that corporate executives demand most, and, fortunately, they are also the devices that corporate IT is most likely to trust. Generally that trust relies on Apple’s approach to the app store – a supposed “walled garden” that keeps the malware out, and allows only well-written and productive apps in. Although the actual merit of that trust is open to debate , trust in Apple has endured.

On Friday, Apple released iOS update 7.0.6 and iOS 6.1.6 without much fanfare and with the advice that users should install it to “fix an issue with SSL verification”. So far, the patch has been issued for iOS but not for OSX, which is also impacted by the vulnerability. Read the details of the vulnerability, and it is clear that this is a serious vulnerability that merits a serious response. Should this vulnerability be a wake-up call to IT to rethink that trusted view of Apple?

How significant is the problem? Should users be concerned?

The short answer is, very significant, and yes users should be very concerned.

The problem lies in Apple’s implementation of a critical aspect of the SSL/TLS (secure socket layer, or its newer revision called transport layer security) protocol – a key foundation of Internet security that allows sensitive information to be exchanged securely over public networks. It turns out that Apple software isn’t performing SSL certification verification properly. This vulnerability leaves iPhone, iPad and Mac computer users open to a potentially serious man-in-the-middle (MITM) attack.

The flaw is caused by a very simple coding mistake in the SSL certificate verification code in Apple’s Secure Transport library. It appears that this flaw has existed since iOS 6, and was still present in the latest beta version of iOS 7.1. Certificate verification is the implementation for one of SSL’s most fundamental precepts – end-to-end trusted communications. The idea behind the SSL certificate mechanism is that an SSL client (e.g., your web browser) can verify the authenticity of a website that it is communicating with by requesting a certificate. This certificate is similar in spirit to a passport – it is a unique, cryptographically secure mechanism for declaring a website’s identity, and, much like passports, certificates are issued by trusted entities called Certificate Authorities. Certificate Authorities take responsibility for ensuring that certificates are only issued to deserving recipients – legitimate businesses whose intentions are not malicious or illegal.
If certificate verification is not functioning properly, the entire system of chained trust falls apart enabling MITM attacks.

In such an attack, a malicious entity is able to intercept “secure” communications between an individual and the intended recipient or website. The attacker is able to read, insert and modify the data in the intercepted communication. The malicious entity can also impersonate a trusted website to install malware or steal valuable data like login credentials and passwords.

A worst-case scenario would look something like this: An unsuspecting user connects to a public WiFi hotspot. If that hotspot had a malicious listener attached to it, that listener could intercept traffic intended for an e-commerce or electronic banking site and steal usernames, passwords, account numbers, credit card numbers, etc. The user would have no warning that this theft was happening, and from the user’s perspective browsing to the malicious site would appear no different than browsing to the legitimate site. This is a dangerous vulnerability indeed.

So what are the implications of this troubling news?

No software is immune from vulnerabilities, and many serious vulnerabilities are uncovered that receive little or no attention in spite of the fact that their impact may be as severe as this issue in iOS and OSX. Apple is perhaps unfairly held on a pedestal, and from that pedestal even the slightest mistake can easily turn into a media storm. However, Apple has made a serious mistake in this case, and it is not the vulnerability itself.

The difference between those vendors that “get” security and those that don’t is in how they respond when vulnerabilities are inevitably discovered. Microsoft has been down this road and back, and prior to Bill Gates’ “Trustworthy Computing” memo Microsoft was the worst offender of all, both in terms of the number of vulnerabilities in their software and their repeated poor responses to them. However, Microsoft realized that growing their business in the enterprise required trust, and building trust with their largest customers meant getting serious about security. The result is not 0 vulnerabilities – that is impossible. The result is proactive, clear processes for communicating vulnerabilities and their impacts to customers and a patching process that allows IT to update effected software without forcing IT to broadly apply major upgrades that may have other, unintended and unwanted consequences.

Unlike Microsoft, Apple’s largest customers are not corporate entities that demand a robust security strategy. Apple builds devices for consumers, and it is these tens of millions of individual customers who are now forcing IT to embrace Apple devices, regardless of whether or not IT has any relationship with or influence on Apple. To some degree, Apple’s response to this issue shows that they are in tune with their customers, and, unfortunately for IT, IT is not Apple’s customer. Apple is not alone in its allegiance to consumers; Google and the Android ecosystem is the same, if not worse. So what is IT to do?

The Answer:

To keep data protected and secure, IT must retain control of the technology that ensures data security and that means entrusting the sanctity of sensitive corporate data with a company that views corporate IT as its most important customer. This does not mean that forcing all end users to Windows Phone is a good, or even viable idea.

Consumerization is here to stay. That means that IT has to adjust to the reality that end users are making device choices, not IT. Device centric security, however, in a consumer-driven mobile market, delivers a very troubling false sense of security.

The solution? A data focused security approach that remains fully under the control of IT and provides the appropriate level of protection and control that IT needs to keep data safe. In this case, when a security vulnerability appears, which it inevitably will, IT has the necessary tools, relationships, and control at their disposal to diagnose and fix the problem on their own timeline for their own users.

Unfortunately, this won’t be the last time that we see stories like this about potentially serious security vulnerabilities in software that we rely on and use every day. However, we do have the option to retake control of the solutions we use to secure our most sensitive data, and to ensure that our sensitive data is fully protected and under our own control.

– Seth

The Dangers of Outsourcing Mobile Security

Posted on by
Reply

Two stories broke recently revealing vulnerabilities in the security infrastructure for Android and iOS respectively. While vastly different in their nature, both point to a fundamental lesson that the enterprise must learn – don’t rely on mobile device OEMs or mobile OSs for enterprise grade security – ensure you are in direct control of security for sensitive corporate information including encryption and access control.

Two separate yet significant approaches to compromising encryption on Android and iOS broke in the news recently. The Android vulnerability, discovered as a result of a compromised Bitcoin transaction, is most directly relevant to encryption. In short, the Android operating system does not properly seed the PRNG (pseudo-random number generator) used by the built-in cryptography APIs. Randomness is essential to ensure that (a) encryption keys cannot be guessed, and (b) an attacker cannot successfully guess the contents of intercepted, encrypted messages. In short, any app that relies on these vulnerable APIs for its essential encryption functions is flawed, including everything from Bitcoin to a vast array of enterprise-targeted mobile apps developed by third party and in-house developers.

On the iOS side, a group of researchers at Georgia Tech successfully submitted an app with malicious capabilities and intentions to the Apple App Store. What the researchers discovered is that the cornerstone of Apple’s App approval process is a static analysis of the app code. How does malware posted to the App Store implicate iOS encryption? Well, the link here is indirect – malware installed on a device can exploit an OS vulnerability to “jailbreak” the device; once “jailbroken” the OS can no longer be trusted, and an untrustworthy OS should not be used for encryption nor should it be trusted to report on its own health and safety when a device management solution tries to determine if it is “jailbroken” or not.

The wake-up call for the enterprise is not in the nature of these attacks themselves – it is in the remediation they require. Enterprises have become adept at managing security vulnerabilities with all of their major vendors, and IT understands that vulnerabilities are a fact of life. The key to vulnerability management is to act on them quickly and effectively once identified. Here we come to the core issue.

Employees access corporate systems with a broad variety of Android and iOS devices. IT can neither upgrade the operating system on Android nor can it influence which apps are admitted to the Apple App Store. IT’s only viable strategy for remediating vulnerabilities in the mobile ecosystem is to attempt to block access to corporate systems or to blacklist access to specific apps. Neither approach is attractive. Locking broad swaths of employees out of corporate systems is not a particularly productive answer. Similarly, attempting to maintain an accurate malware blacklist is destined for failure (see anti-virus).

IT’s best (and only) strategy in a mobile enterprise is to retain complete control of the components of the mobile software stack that matter most. Encryption and access control are the building blocks of the mobile security infrastructure, and the software implementing these two operations must be as firmly in IT’s control as is possible. In practice, this means that a software-only container, which includes its own full stack implementation of all cryptography functions and all secure network protocols (e.g., a full SSL/TLS stack), should be the only software trusted to handle sensitive corporate data and to authenticate corporate users. This strategy is not perfect because no software (including the container itself) is perfect, but it restores control to IT when vulnerabilities are discovered.

As IT quickly loses control of the endpoint devices that employees choose to access corporate systems and data, IT must consider carefully when and where it is essential to retain control and how to do so. When security really matters, a secure container approach is the only answer. The question from there is how to deliver a first class mobile experience while still retaining the protections that a software container affords. As without a rich and compelling user experience, users will be reluctant to take advantage of the mobile app irrespective of its level of security.

– Seth

A smarter approach to securing sensitive corporate data while increasing flexibility and reducing complexity. Too good to be true?

Posted on by
Reply

We are going to be talking about security a lot because we see some real issues with the current enterprise security models and we also have some smart and practical ideas about how to do it better. To help frame our thinking at the highest level, it all starts with a shift in focus to securing sensitive corporate data and not the device that is being used to access it. This shift is profound, and has impacts on the whole enterprise security paradigm.

Over the last 10 years, corporate IT has witnessed an astounding transition often called “consumerization”, but better termed “empowerment”, as individual employees have assumed the right to seek and adopt the tools that they need to best execute their jobs. Consumerization has had a profound impact on IT’s software infrastructure, and now its impact is extending to endpoint computing devices. Technology has arrived at the point where IT can cease to treat the various devices that employees use to interact with corporate data and applications as infrastructure, and can treat them as tools.

Infrastructure should be centrally managed and controlled by IT. However, the increasing device diversity in today’s endpoint computing market does not fit with a “command and control” model. Diversity in form factor and operating system encourages consumers (who are also employees) to adopt the devices that best fit their personal needs, budget and preferences. As such, IT’s preferences are becoming increasingly irrelevant, as employees find a way to bring their chosen tools to work – starting with mobile phones and then tablets and now leaking into other computing devices. Hence, IT needs to recognize that devices are tools, not infrastructure, and IT can (and should) embrace this transition.
Rethinking endpoint devices as tools requires two fundamental changes in thinking for corporate IT: (1) applications infrastructure must migrate to a ubiquitous platform, not a vendor or device-specific platform, and (2) endpoint security must focus on data, not devices.

Corporate applications, whether they are built in-house or built by a 3rd party, must operate on any device to enable employees to choose the best and most convenient device tools for their jobs. IT has already made great strides in this area – application infrastructure for “fixed” use has increasingly moved to the corporate intranet or, more recently, the cloud. The web and the browser is already a ubiquitous delivery vehicle. What has been missing is the full feature set required to power IT’s complete application stack across both fixed and mobile access and use: including sufficient performance, offline access, flexible and powerful graphics, and a complete client-side programming language.

HTML5 is very close to being that platform. Where gaps in the standard remain, PhoneGap (now Apache Cordova) is a viable, cross-platform, and open source option for closing those gaps through simple integration. Hence, with the browser as the target application platform, IT can build a unified applications suite targeting devices as varied as smartphones and desktops.

While HTML5 addresses the development and delivery of applications to any device, it does not necessarily secure the data. However, browsers do solve one of the most important aspects of endpoint security via the https protocol – browsers can ensure end-to-end trusted communication to the corporate network. Hence, a security solution for browsers is simply a matter of securing data at the endpoint and leveraging the features already available in the https protocol to ensure trusted communications.

Notice that device security plays no role in securing corporate data delivered through a browser. IT cannot keep up with the diversity of devices employees will demand while dragging along an expensive and complex software security stack (including anti-virus, personal firewalls, full-disk encryption, network access control, application whitelisting, mobile device management, etc.) to secure them. A more reasonable and effective goal than securing all devices touching corporate data is to secure all apps touching corporate data. The more those apps converge on the browser as the delivery platform, the more this challenge reduces to building a secure, cross-platform corporate browser. In brief, building a truly secure corporate browser requires:

• Full encryption of all client-side data
• Client and server validation using https’ certificate validation features
• Protecting access to corporate apps with a unified sign-in
• A comprehensive data policy engine built into the browser that allows policies for data sharing and offline access to travel with the data itself and be contextually aware
• App-level device-independent implementation of all critical security functionality to ensure that security is not compromised by a compromised device or operating system

A secure browser that enhances the rendering and communication features of a standard browser with the additional security features outlined above enables corporate IT to build a unified applications platform that extends across devices of all shapes and sizes without compromise in functionality, performance, or security. The endpoint device then transitions to a tool for employees to select, rather than another piece of infrastructure that must support the sanctioned IT software stack to ensure its acceptability in the corporate environment.

Mobile security is part of our mission at Mobile Helix. We provide our customers with highly secure solutions which allow their employees to meet and exceed the company’s business objectives. Our solutions support this approach to security – to find out more about them, please go to our website: www.mobilehelix.com

.

– Seth