Tag Archives: Core Data Services Network

The Home Depot Story

13 November 2014

After two month of investigation the reason for the Home Depot data breach appears to be clear: Cyber criminals used stolen credentials from a third-party vendor to enter the Home Depot network. In a report by Mike Davin from November 7, 2014 one could read some more details: ‘The hackers then acquired elevated rights that allowed them to navigate portions of Home Depot’s network and to deploy “unique, custom-built malware” on its self-checkout systems in the U.S. and Canada.’

It’s a complete mystery to me why companies do not secure the access to business critical data with Two Factor Authentication. TFA would severely hamper such data breaches. I am not overly surprised that the attacker could acquire elevated privileges.

But what really worries me is that the attackers we able deploy software to the company’s point-of-sales devices. It is quite obvious that the software deployment process is not sufficiently secured and could be easily tampered.

From my point of view Home Depot’s IT should invest some time in threat modelling of the software deployment process to avoid such incidents in future. In particular the strict enforcement of the Separation-of-Duties principle will prevent unplanned deployment of critical Software.

Have a good day!

Advertisements

My favourite tools – Remote Desktop Services

7 August 2014

Remote desktop or terminal services are my favourite tools. When I started with this technology in 1997, it was bare necessity. We had to offer a 2 tier CAE application to about 500 engineers at 3 major sites in 30 buildings. The fat client graphics application was installed on Windows NT workstations. Data was stored in about 120 Oracle V7 databases hosted on 3 SUN database servers. It was a really hard job to keep the client workstations up-to-date, in particular because everyone was working with permanent admin rights. The nightmare of all system administrators!

Terminal Services put an end to this nightmare. Since users had no longer privileges on the servers the number of help desk calls declined dramatically. Release changes were implemented within an afternoon and new users were authorized to the application within minutes.

We gained back control, and my kids had their father back.

Today, terminal services are my preferred method to control access to the core business data. They are really low hanging fruits! This is the major use cases:

(1) Block access to the data  from all systems except of few terminal services. This will reduce the attack surface dramatically. The terminal services are the only trusted end-user devices in your network. Located in the data center they are in the best case completely under your control. It’s easier to keep the trust state of few servers as the trust state of hundreds of workstations located elsewhere inside or outside the company network.

(2) Grant access to the terminal services to authorized users only, based on the Need-to-Know principle. Review authorizations on a regular basis and make sure, that no user owns the permissions to change his own privileges or the trust state of the terminal services or any other infrastructure service.

Even if an application does not support user and role management the combination of (1) and (2) will increase the security of your information assets dramatically

(3) Terminal servers allow you to restrict users to well-defined applications and data sources with low effort. This could be implemented by configuring the firewalls on the terminal services. Just block any outgoing network connections except of infrastructure services and the applications. Users are prevented from creating unauthorized copies of the data.  In addition, the Need-to-Know principle is enforced because only the information essential to the users work is provided.

(4) It’s far easier to implement Two Factor Authorization for a limited number of terminal services than for thousands of endpoints. Targeted phishing attacks will no longer work because the password is no longer the single source for identification.

The transformation to terminal services controlled computing is very easy because you can set up the systems and applications in parallel to the existing application infrastructure. The final switch will have nearly no impact on the user’s daily work if the entire process is governed by change process.

Have you ever decided about a BYOD strategy based on Remote Desktop Services? Terminal services are a perfect measure to raise the trust level of the entire network, in particular when combined with your employees own devices.

But this is another story…

If you have any questions, please feel free to leave a comment. And enjoy the free time with your family.

Howto secure business critical data? – The admin challenge or {U} ∩ {A} = ∅

17 July 2014

Unfortunately, sometimes administrative privileges are required for operation of the systems and services inside the Core Data Services Network (CDSN). This is very annoying because administrators are always an inherent risk. To be honest, I look forward to the day when servers could be operated without any system privileges.

Until then, we must try to reduce the risk through consequent application of the Separation of Duties (SoD) principle. Let’s do some basic set theory first.

Let {U} be the set of all employees in the company, {D} ⊂{U} the set of all employees with authorized access to the core data and {A} ⊂{U} the set of all IT Administrators in the company.

The Separation of Duties (SoD) principle requires:

 {U} ∩ {A} = ∅

This translates into the following basic principle:

Employees with authorized access to core business data must never have the privileges for administration of systems and services in the entire company network.

Could a data manager have privileged access with a special account? This question was asked in a meeting some days ago. Although there may be good reasons to do this, the answer is No. Never! Employees with authorized access to data must never have privileged access, no matter what account is used.

Note bene: The SoD principle should be applied to all services at all system, application and infrastructure levels. Let me clarify this by the means of two examples:

  1. Data managers should never have the privileges for account or database administration because this would allow them to grant privileges to themselves.
  2. Terminal service administrators must never have the privileges to configure the firewalls between the CDSN and the company network. This would allow them to authorize other computer for access to the CDSN.

Simple, but effective.

Howto secure business critical data? – Build an effective data export control system!

3 July 2014

In post How to secure business critical data? – U.S. Customs and Border Protection shows the direction! I introduced the Core Data Services Network (CDSN) where business critical data is isolated from the company network.

One-Way traffic sign

Source: Wikipedia

The network connection into the CDSN is implemented as a one-way connection. Except of infrastructure services (e.g. Directory Services) the firewall at Atlanta blocks all outgoing traffic, which makes data theft nearly impossible. For advanced security levels even the infrastructure services should be provided from the CDSN.

Unfortunately, we have to exchange data with the CDSN. Again, the U.S. Government shows the direction by the means of export regulations. For details please see Overview of U.S. Export Control System.

In our case a Core Data Exchange Service (CDXS) is set up inside the CDSN on server Miami Beach. Users of the Atlanta Application Services could copy business data to Miami Beach, but are not authorized to intiate the transfer to Frankfurt from inside the CDSN.

The data from Miami Beach are provided to the users in the Company Network exclusively through the Frankfurt data exchange Services.

CDSN-Overview with CDXS

Core Data Services Network Overview

The data transfer is governed by a process with clearly defined roles and responsibilities. It’s this process that makes the difference. The technology used is standard windows technology, no rocket science!

First of all we have to define an new  role Data Exchange Manager (DXMgr). Only DXMgrs are authorized to copy data from the Miami Beach Core Data Exchange Service to the Frankfurt CDXS. The DXMgrs must never have access to the data as a Data Manager (DMgr) and a DXMgr must never initiate a request for data from the CDSN.

Data Exchange Workflow

Data Exchange Workflow

(1) The DXMgr takes the request for data from an authorized employee (Requester), checks whether the request is valid and (2) forwards the request to an employee with role Data Manager (DMgr).

(3) The DMgr validates the request, connects to the Atlanta Application Services, creates the requested data and copies them to the Requesters write-only inbox on the CDXS at Miami Beach. During this process the data is encrypted with the key of the Requester.

(4) Back in the company network the DMgr sends a notification to the DXMgr. The DXMgr connects to the Frankfurt CDXS, copies the data from the Miami Beach CDXS to the write-only inbox of the requester on the Frankfurt CDXS and deletes the data from Miami Beach.

(5) Finally, the DXMgr notifies the requester to check and empty his inbox on the Frankfurt CDXS.

Sound’s easy, doesn’t it?

This home-made solution, based on standard Windows features like shares, mapped network drives and finegrain acl, is somewhat complex to set up and to maintain. I would recommend to use a secure and user-friendly ad hoc file transfer solution which is easier to manage.

How to secure business critical data? – U.S. Customs and Border Protection shows the direction!

26 June 2014

Reflections, Boston 2013

Reflections, Boston 2013

Last year we spent our vacation at the U.S. East coast. We started in Boston and headed north to Acadia National Park, a really wonderful place for German tourists.

Vacation in the U.S. is for Europeans a somewhat strange experience. You have to take some hurdles before you finally arrive at your destination.

First of all your eligibility to travel in the U.S. is determined. All Visa Waiver Program travelers have to get a travel authorization via ESTA (Electronic System for Travel Authorization). If ESTA rejects your application you have to apply for a VISA. It would not have been possible to step on-board the plane in Düsseldorf without a valid travel authorization.

But authorization via ESTA is not the final permission to enter the United States. In our case the U.S. Customs and Border Protection officers in Atlanta determined the admissibility during the intermediate stop.

This is an easy to adapt security concept for business critical data:

[1] Isolate your business critical data from the company network into a Core Data Services Network (CDSN). Figuratively speaking the CDSN is the United States.

[2] Boston is a data service, Atlanta an application or terminal service inside the CDSN. Access to the data in Boston is possible only via the applications provided by Atlanta. The way back to the company network is blocked! Export regulations are fully enforced!

Core Data Services Network Overview

Core Data Services Network Overview

[3] Düsseldorf is the gateway to the CDSN. Access to Atlanta is only possible via Düsseldorf!

[4] An employee must login to Düsseldorf first and open a remote session to Atlanta. On Atlanta he has to be authorized for the applications to access the data in Boston. At least for login to Atlanta a Two Factor Authorization should be in place to prevent eBay like attacks.

Many thanks to the U.S. Department of Homeland Security for this really easy to adapt security concept.

Sometimes you have to export data from the CDSN into the company network. U.S. Customs is involved through export regulations, but this is another story…