One of the selling points of Enterprise Resource Planning systems like SAP or Oracle E-Business Suite is their claim to give management visibility across the business, by aggregating (or at least integrating) data on different facets of business operations. Taking these claims at face value, how are ERP systems set up when a company such as a defence contractor carries out classified business?

The problem I'm imagining is that classified information could be infered from otherwise "boring" business data. For example:

  • HR information on job title, location, or specialist qualifications held by staff could reveal the nature of classified work being carried out.
  • Purchasing or Accounts Payable records could reveal sensitive subcontractor relationships or details of classified products the company develops.
  • Even the company's Chart of Accounts could reveal the existence and size of otherwise unacknowledged projects.

I've never had to solve this problem myself, but I can think of a few ways an ERP system could support a company's conflicting obligations to safeguard classified information and to maintain detailed records for audit and management control:

  • The system's built-in security features could be used to limit access to some data, while still allowing summary information to "roll up" to a safe level of aggregation (e.g. uncleared users might see a single GL account "Net classified income" with no further details). This would give cleared users or auditors an integrated view of the business, but has the disadvantage that anyone with privileged access to ERP data (system administrator, DBA etc) needs clearance.
  • A separate classified instance of the system could be stood up, and all classified business recorded there - effectively the time-honoured accounting practice of running two sets of books. This would require a feed of unclassified summary data to the main system, which would treat the classified instance as one more external data provider. The obvious problem here is cost and keeping the two systems' configurations in sync.
  • Classified data could be "hidden in plain sight", e.g. by using opaque project codes or account descriptions that don't give away sensitive information. This might work for job titles, but someone somewhere still needs to know that "Project X-123" is actually "Sharks With Frickin' Lasers" which seems to defeat the purpose of the system.

In general, how do ERP system implementations handle this situation?

  • 2
    This is more a question about how SAP or a similar ERP can be developed and configured to comply with such demands. Just note that in the case of SAP historical data will always be there, so you will have both GDPR and security problems without special development of this area. – Overmind Mar 13 '19 at 9:38

Generally speaking, there is no inbuilt functionality that will facilitate this. The level of isolation required simply can't be patched into an ERP product after it is developed. SAP, particularly, is somewhat of an eldritch horror in this department.

The only effective solution I've seen used is to run a separate instance on separate infrastructure for cleared work. Anything of normal sensitivity (f.e. up to commercial in confidence) goes on the regular instance, anything secret or above goes on the cleared instance.

Of course it is often useful or necessary to have metadata about the cleared instance available on the normal instance. This can generally be facilitated by implementing a plugin on each instance for the purposes of intercommunication of that metadata, with an intermediary system that helps enforce the data contract for security purposes.

Information sharing can still be performed carefully, by installing plugins on each instance that allow for the export/import of data, and having the instance infrastructure able to communicate over only a fixed channel (e.g. HTTPS on a specific port, enforced by firewall appliance). Here's a diagram of an approach I've seen used before:

Isolated instances

A gateway server runs a web service on a pair of ports - one for cleared-side connections, and the other for normal-side connections. It VPNs into both networks and the VPN endpoint applies firewall rules specific to that connection, allowing only inbound connections to the gateway on the correct port. The web service consists mostly of a service endpoint that validates incoming data, and a message queue that the data is placed into. Each ERP server plugin instance can connect to the gateway to send and receive messages. By combining host-based firewall rules on the gateway itself and appliance firewall rules on each side of the network, it becomes exceedingly difficult for an attacker to directly penetrate from one instance to the other.

The firewall on each side contains a rule and a route that allows the ERP instance on each side to communicate with an identity provider for user authentication purposes. This should allow only outbound connections from the ERP instance to the identity provider on the necessary port.

The VPN also allows for management connections from a whitelisted IP address range, using separate VPN credentials. For these connections a relaxed firewall rule set can be applied, but it is worth blocking new outbound connections from the instance network to the management LAN because such connections should not occur in general (and change requests can be raised if such a connection needs to happen for some reason).

The users can VPN into each instance. The blue arrow colour indicates the allowed access, i.e. the users can only access the ERP analytics front-end rather than any management features or database instances. For convenience a routing device can be placed on the user LAN which has a permanent VPN connection into the normal instance, to avoid needing VPN clients on every standard user's machine. Users who require access to the cleared instance can then VPN in separately.

You can enhance this layout in a number of ways. For example, the gateway server could have an attached log store which both instances send logs to via the web service. This means that even if an attacker compromises an instance, the logs cannot be destroyed.


It depends how big is the business. Medium-Big corporations have DLP protection which protects from internal data leakage. Like if somebody is sending VAT, number or some "secret" the DLP is triggered and admin is contacted. Also advanced DLP nowdays is artificial itelligence, which by it self recognizes important data.

  • 1
    I have tested most of the commercial DLP solutions. They only generally work against accidental data loss (e.g. putting a sensitive document on a public share) and the more functional ones require access to all of your document stores, which is a regulatory nightmare if you require separation of cleared and non-cleared data. An attacker trying to exfiltrate data will almost certainly not be noticed by DLP - simple obfuscation or encryption (even HTTPS) generally defeats it. – Polynomial Mar 13 '19 at 11:07
  • This does not answer the question at all. DLP runs at the wrong layer of technology to even apply to the situation. – schroeder Mar 13 '19 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.