In this issue we shall look at BYOD with a view to identifying the major risk factors affecting the design of a technical architecture supporting BYOD as a way of working, suing as always the SABSA way of thinking.
The most important thing to consider is the business risk – from both sides of the employer/employee relationship, and from both sides of the risk/reward balance. BYOD presents both opportunities and threats, both to the employer and to the employee who owns the device. The assessment of these risks is something that both parties should undertake independently. BYOD security is a collaborative exercise between the owner of the device and their employer. Each party has some security and risk management requirements. It is a mistake for the employer to assume that they are taking control of the device – they are not – they are sharing its use. Thus the employer may not impose any restrictions on the private use of the device by the owner. That is a policy principle that must be established before any technical architecture can be considered.
The owner of the device uses it for private, personal applications and data, and should be protected from these being accessed by the corporate centre. At the same time and on the same device, corporate data and applications must be processed without leakage from a corporate domain to the public domain. The user must be free to make decisions as to which applications they will run for personal private use, and must be free of corporate restrictions on what these choices will be, otherwise the device ceases to be ‘owned’ by the user, and is no longer an ‘own device’.
There are also many technical constraints that must be taken into account. Any data stored on the device cannot be differentially secured. Access through the keyboard and other input/output devices must be shared. The operating system on these types of devices does not support multi-user segmentation. Any local data, however it may be presented through various applications, is, at the lowest level, stored as a series of raw files. If you can access one you can access them all. The result of this constraint is that the architecture should not rely on local storage of corporate data. All data should be stored on a central corporate server. That immediately suggests a thin client architecture, in which the client software has minimal functionality, restricted to setting up a VPN connection to the corporate network and allowing thin client agents to be run on the device. A thin client is a virtual presentation only. No actual data processing is done on the client device. Data is transferred to and from the device and all processing and storage is done on the central server.
Malware is a serious technical threat that must be regarded as a major attack vector, especially into the future when malware capability will only increase. Such malware is known to be able to monitor keyboard strokes, take screen-shots and sniff other input/output channels. So, an architecture that allows a corporate application to have direct access to the hardware and operating system will necessarily have a low level of security, since malware can monitor all this activity. That may be avoided by creating a sandbox for the thin client application and by using only keyboard screen images for data entry and randomising the positions of the required mouse clicks on the screen.
In summary, both employee and employer must make risk based decisions about what type of use will be made of BYOD services. If the level of business criticality is very high, then perhaps those specific applications are unsuitable for this approach. However, if a technical architecture along the lines described here can be designed to a sufficient security level, then BYOD has many attractions. SABSA is all about being driven by business risk, and there is no difference here. Being business risk driven will always be the overriding principle for security architecture design.