PDF

swipe to navigate

Security objectives

Neither the BYOD device nor the public Internet where it is attached can be trusted:

  1. The user's device might be infected with malware (key-loggers, packet sniffers, etc.).
  2. The Internet is home to various attackers, ranging from kids trying to see what they can get away with to criminal gangs and state actors engaged in cyber espionage and cyber sabotage.

For these reasons, most organizations operate a secure, private network with firewalls protecting all connection points between this network and the public Internet. There are often intermediate networks between the private, corporate network and the untrusted, public Internet -- called demilitarized zones (DMZ) -- where web servers, mail servers and other systems that must be publicly accessible are installed.

Security-sensitive systems and applications, such as a corporate identity and access (IAM) system are most commonly deployed on the private corporate network. This placement makes IAM systems (intentionally) difficult to reach from the public Internet.

The relationship between these components - BYOD, IAM system, private network, public Internet -- is shown in Figure [link].

Relationship between BYOD, public Internet and private corporate network

Relationship between BYOD, public Internet and private corporate network

In offering a solution that enables a BYOD device to access an on-premises application, the following security characteristics must be ensured:

  1. By default, block any public IP address from accessing any on-premises system -- only authorized devices should be able to connect to the IAM system.
  2. Block even authorized devices from accessing anything on the corporate network other than the IAM system.
  3. Protect systems and applications on the private, corporate network against (possibly distributed) denial of service attacks.
  4. Do not publish user IDs on the public Internet.
  5. Link authorized devices to known user identities. Only allow users to access the IAM system from their own device, not someone else's.
  6. Activate devices for access, with the ability to deactivate those devices if lost, stolen or if the user in question leaves.

Network architecture, firewalls and connection problems

In Figure (Screenshot:byod-relationship-internet-corp-network), it is clear that, without opening connections through the various firewalls, there is no way for a user's device to connect to the on-premises IAM system. The question then is "why not just ask the firewall administrators to open whatever ports are required to enable this connection?"

In practice, firewall administrators are justifiably reluctant to allow any inbound connections, originating on the public Internet and terminating at network addresses on the private connection. On the other hand, many systems on the private network require the ability to connect to public Internet addresses. In other words, the direction of the connection matters -- outbound connections from the corporate network are routine, while inbound connections are risky, complex and undesirable. This is illustrated in Figure [link].

Outbound connections are routine, inbound connections are risky and rarely permitted

Outbound connections are routine, inbound connections are risky and rarely permitted

The challenge is that the desired connection, required to enable a mobile phone to access a corporate application, is precisely what is not allowed, as shown in Figure [link].

Desired connection is precisely what is not allowed

Desired connection is precisely what is not allowed

PDF

Comment via LinkedIn