Maksim Kabakou - Fotolia
Security Think Tank: In-app segregation more intelligent and permissive
What are the security benefits and challenges of segregating IT environments, and how best are these challenges overcome?
Preventing unauthorised persons breaking and entering the corporate IT environment in the first place is clearly the preferred option when tackling cyber crime.
But, based on the evidence that most organisations will get hacked at some stage, segregating systems within the network, which limits intruder access after a breach, is also a key tool in the battle.
States of segregation
In its simplest form, segregation involves separating systems and devices within the network. If one system is compromised, it is possible to limit the infection to just that segment. It is usually enabled through individual systems running on dedicated servers that can be included in specific network partitions, usually separated by firewalls.
Alternatively, for organisations that have deployed industrial control system (ICS) networks, sensors and processes, devices are segregated on their own network to prevent unauthorised access to critical processes and unintended downtime due to accidental changes and scans.
That’s the theory. However, as with many IT issues, the real-life version isn’t so straightforward. An organisation that manages highly confidential contracts or has critical or sensitive systems and devices can clearly justify protecting its IT applications and devices from anyone but essential users. But most organisations aren’t that singular in their purpose.
An engine supplier, for example, may have several business units with different levels of sensitivity. Information pertaining to its automotive operations, while commercially sensitive, will be less highly classified than details of its engines being fitted to nuclear submarines.
In a similar vein, some operations at a professional services company can be made available to all employees because they are not particularly sensitive, whereas other projects, contracts or subject matter may be so highly sensitive that even knowledge of their existence is deemed a security breach.
Simon Persin, Turnkey Consulting
In other words, enterprises will have different protection requirements for the different areas of their business. It is critical that there is a clear understanding of both the security needs and the classification levels so the right policies, standards and approaches to the IT landscape are deployed, along with the appropriate segmentation – if any.
In today’s IT landscape there is a significant driver to adopt cloud-first, multi-tenanted applications, often hosted in the public cloud. While financially compelling from a business perspective, this is at odds with the aspirations of segregation. Even co-hosting applications on the same server does not constitute segregation in its truest sense. It is important, therefore, to understand just how segregated the application needs to be.
Robust segregation allows an organisation to strengthen preventative controls to stipulate who or what can access the application. This could include stringent firewalls, access-driven malware and virus scanning, limitations on ports being opened and geographical restrictions on where and how the network can be accessed. This can be augmented with additional monitoring and manual controls to detect and react to potential threats more systematically, thereby providing additional assurance.
Security versus operational efficiency
Improving security in this way, however, also increases the rigidity of business operations. For example, the approval process for information within a “secure” zone is likely to be rigorous, which takes longer and potentially increases the lead times for achieving the overall objective. Every permitted connection, whether human or system-based, represents a potential threat to the security of the segregated area. This increases the requirement to have robust and effective monitoring controls, but also theoretically reduces the overall security stance of the zone.
If secure segregation is a desired approach, applications must be completely standalone, with no need for external connections to applications outside of the secure zone.
This makes enterprise resource planning (ERP) systems a big cause for concern as they are often integrated systems performing a number of business processes and rely on the interconnectivity of data. Some of that data could be highly confidential, such as the stock levels and location of enriched uranium for nuclear reactors or the physical location/addresses of key individuals, while some will not be critical, such as purchasing information for office supplies.
It would be counterproductive to adopt the highest level of data security throughout the application, which would treat each standard business transaction as highly secret, yet classifying everything by the need to have efficient business processes that depend heavily on real-time and shared data access points is clearly not an option. This is the age-old conflict of security versus operational efficiency.
This conflict leads to the consideration of in-app segregation and application-level security, which limits access within the application to appropriate levels.
In-app segregation requires a diligent and well-implemented authorisation and security design. Security requirements should be fully explored to provide an accurate blueprint of what is needed from the authorisations solution, and the system carefully tested to ensure that security restrictions are universally applied. Often, this is not the case – when performing authorisation design assessments, Turnkey has seen examples of highly confidential data being easily accessible without any need for superuser authorisations, despite assurances that it was locked down.
Simon Persin, Turnkey Consulting
Because it is no longer a simple binary choice to access the system, complexity is added to the control environment. Security information and event management (Siem) tools can determine whether the network servers have been compromised by an external threat. However, they only identify whether or not the system has been penetrated, which is virtually meaningless unless it includes the context of what has been compromised – whether it’s top secret or less sensitive, for example.
Despite the additional layer of complexity in the authorisation setup and control monitoring scenarios, applying in-app segregation does facilitate a vastly improved level of control. Secret information can be restricted by specific authorisations and roles, meaning that only those who are deemed appropriate and authorised have access, while those who do not explicitly require access to the information can go about their general tasks without impact.
In-app segregation encourages a more intelligent and permissive way of working that can also unlock more efficiencies by allowing the interconnectivity of systems and data – customer self-service, automated stock reporting or supplier self-billing, for example – while still providing an appropriate level of security and control to the business information.