Tag Archives: Separation of Duties

Malware in SQL – Really new?

18 February 2017

In post ‘Magento stores targeted by self-healing malware that steals credit card details‘, published by David Bisson on 18 February 2017 at Graham Cluleys’s newsletter, I found the really astonishing statement from Willem de Groot:

This is the first time I see malware written in SQL.

What happened? To put is briefly, someone found a vulnerability in Magento-powered online stores. He guessed the web shop’s administrator password. With this, he managed to get the database schema user’s username and password, connected to the database and added an after-insert trigger to the sales_flat_order table. The after-insert triggers adds code to the web page which sends customer credit card details to the attackers C&C server.

To be honest, there’s nothing new here.

As in 90% of all data breaches, a vulnerability known for some month was used to get administrative access to the shop software. For details please see post ‘10 tricks to improve Magento admin security‘.

But this must not necessarily end in a data breach. The issue here is, that the admin user was used to get privileged access to the database. This kind of trouble can be easily avoided by strict separation of duties inside the database. Only the database schema owner should have the privileges to change the database schema, i.e. add a trigger to a table. All other database users should have the privilege to access data sets only. And the web shop software administrator should have no access to database content at all. That’s plainly long known database design best practice.

In general, database application designers spend a lot of time ensuring data integrity. Data integrity was not violated here. In this case, we encounter code integrity issues, which result in the loss of confidentiality.

Separation of duties is the standard means for mitigation of this kind of issues. In addition, we should consider adding code integrity checks to ensure code integrity at runtime.

Have a good weekend.

How to Mitigate the Risk of Cyber Attacks? The Principle of Least Privilege shows the Direction!

21 March 2015

Lysa Myers writes in ‘Premera Breach: Healthcare businesses in the crosshairs‘, published on 18 March 2015 in welivesecurity.com about ‘five things businesses should be doing to help decrease risk and mitigate damage in case of a breach.’

I find it most remarkable that one of her recommendations is to enforce the Principle of Least Privilege in daily business. In my opinion this is the right step in the right direction.

Enforce the principle of least privilege across the entire IT infrastructure and application stack and you will gain back control.

For example, access to the company network should be granted only to those people who need this to do their job. In addition, access should only be possible during standard working hours, and, in the best case, from a single computer at a time.

This will prevent attackers from accessing the company network outside the working hours and from using an account during working hours from another computer.

From this example it becomes clear that to enforce the Principle of Least Privilege changes have to be applied to all sides (People, Processes and Technology) of the Golden Triangle of IT security.

In addition, the principle of Separation of Duties should be enforced for access to business critical information. In any case, access to critical information should be approved by the information owner. In the best case, access should only be possible if the information owner and the employee are logged in at the same time in the application system.

Enjoy Lysa’s post, and have a good weekend.

Anthem Hacked – The call for ‘More of Everything’ grows louder

19 February 2015

Just some thoughts about the call for more technology, encryption, pen testing, etc.

The big question is: Would database encryption have slowed down or stopped the attackers? From my experience with Transparent Data Encryption (TDE) in the Oracle universe I can only answer: Definitely Not!

If it’s properly set up TDE works very well to prevent unauthorized access to data in rest. Administrators and users are not able to read or copy database files when e.g. the database is shut down.

But as long as the database is started TDE works transparent for all users and the administrators: They can access the data with applications or SQL tools without any restriction.

If you like to keep the administrators away from the data you must set up Oracle Database Vault on top of TDE. Database Vault acts as a firewall between the users and the administrators. Administrators can run their administrative tasks, but they could no longer access the data. In addition, the Separation of Duties principle is enforced for security critical operations like definition of users.

But what’s about malicious insiders? Malicious insiders are responsible for about two-third of all attacks, but neither TDE nor Vault would stop them from accessing all data. With Label Security a fine-grain access control system is available that gives data admins the opportunity to restrict a user to individual data sets in a table.

Sounds like rocket science, doesn’t it? Far from it. Most of this products are for several years in the market, but they are widely unknown, and, the effort for implementation is high.

That’s it for today.

For further reading please see

Anthem Cyber Hack: 5 Fast Facts You Need to Know

Anthem Breach Should Convince Healthcare To Double Down On Security

Anthem Breach Prompts New York To Conduct Cybersecurity Reviews Of All Insurers

Isolated security measures make no sense!

27 November 2014

In the past days I did lots of application protection planning with Oracle databases as backend.

Oracle SQL*Net encryption is an easy to implement measure for protection of the network traffic against sniffing attacks in a standard client-server application with an Oracle database as backend.

Why is encryption of the Oracle network traffic such important? Because everyone who can edit the sqlnet.ora configuration file is able to set up Oracle network tracing by adding just some configuration parameters.

With tracing enabled the entire session traffic, e.g. a change password command like

Alter user system identified by ",v$1ry c2mplex p$3ssword!";

is logged in plain text to the trace file. That’s extremely dangerous! Never change your password this way!

But the output of a standard SQL command like

 Select employeeName, employeeSocialSecNumber from employees;

will be reported in plain text as well, even if column ’employeeSocialSecNumber’ is secured with Oracle Transparent Data Encryption option. Works as designed, transparent to the user. Even if the user takes care of the data the attacker with admin privileges could easily create a copy from the trace file.

With SQL*Net encryption activated the trace is no longer readable.

SQL*Net encryption is set up by just adding some configuration parameters to the sqlnet.ora file on the clients and the server. Thus everyone who is able to edit the sqlnet.ora file on the client could potentially disable encryption…

Fortunately parameter SQLNET.ENCRYPTION_SERVER set to REQUIRED on the database server controls session behaviour. A client connection attempt with session encryption disabled will be rejected with error message ORA-12260. Great!

But all server admins are able to edit this configuration file…

What can we learn from this?

Applying isolated security measures will not raise the overall security level.

The House of Security

The House of Security. Click to enlarge.

The combination of security measures makes the difference!

Happy Thanksgiving!

The new first line of defence?

22 November 2014

In his latest post at ComputerWeekly.com Warwick Ashford reviews the CyberArk Report ‘Exploits of Privileged Accounts Shift the Front Lines of Security’. His post is absolutely worth reading.‘

‘“One of the reasons for this is smaller, less well-defended organisations have become a prime target for attackers who are ultimately aiming at larger partners in the supply chain,” said Mokady.’

That’s definitely true. Perhaps you remember the Home Depot data breach? This breach was caused by stolen credentials of a third-party vendor.

‘“Securing privileged accounts represents the new first line of defence in the ongoing cyber battle companies are fighting,” he added.’

Very well said. But what really confuses me is that Udi Mokady talks about the new first line of defense. 

The majority of the big data breaches have been caused by stolen credentials. With a Two Factor Authentication (TFA) most of this breaches could have been prevented.

It’s definitely very important to secure privileged accounts. With admin privileges it is very easy to change log settings or tamper audit records. But it is definitely not enough to secure only privileged accounts. Because even with standard user privileges you may have access to business critical data to do your job.

Let me give you an example. Oracle Transparent Data Encryption and SQL*Net encryption and integrity checking are easy to implement measures to secure an Oracle database. This will prevent man-in-middle attacks, eavesdropping of the data traffic and direct access to the database files.

Sounds pretty secure, doesn’t it? Unfortunately it isn’t. Even an unprivileged user, and even more a malicious insider with stolen credentials, is able to install an oracle instant client and use Excel and ODBC to create a copy of all data he could use with his standard user rights.

With TFA enabled, at least on all business critical systems, and for all users, the probability of such an event is dramatically reduced.

Securing accounts with TFA is the very first line of defense.

In addition you should decide about granting privileged access on a per task basis. For business critical infrastructure and applications an administrator should receive an authorization and one-time-password for just one task. At log off the authorizations are dropped. In the best case the admin group for a windows servers is empty. Only the local admin could always logon, but his password is in a safe place.

The authorization process should be implemented with strict application of the separation-of-duties principle, and the permissions should be granted with strict Application of the principle of least privilege. Important: The employees who grant authorizations and privileges should never have the possibility to grant whatever privileges to themselves.

Moreover the consistent application of the principle of least privileges even for standard users and processes will significantly reduce the attack surface of your company.

Nothing really new, just the same old story.

Glacier near by Grächen, Switzerland

Glacier near by Grächen, Switzerland

Have a good Weekend.

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!

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.

Will IT security technology solve the Snowden Problem?

10 July 2014

In the year one after Edward Snowden discussions about the why and the how are well under way. In the past month all suppliers of IT security technology made proposals how to tackle the Snowden problem. Additional technology like an integrated Tagging/Encryption/DLP system seems to be a solution to the Snowden problem. But would the data theft have been prevented by such a solution?

Since Snowden had legitimate access to classified information the answer is: Definitely Not!

We have to dig somewhat deeper into IT security concepts to get to the root of the problem.

The big questions are:

  • Why has an employee with legitimate access to classified information the right to create copies of this information?
  • Why is he authorized to bring the information outside the organization?

The concepts and processes for handling of classified information were designed more than 40 years ago and remained nearly unchanged over the years. Because technology developed rapidly during this time we face a constantly increasing gap between the technology used for attacks and the concepts we use to secure our information.

Although we patched our outdated concepts and processes with advanced technology during the years, we never got the most of this new technology. In a poorly designed environment even the best technology will deliver poor results only.

In order to bridge the gaps the entire system and process architecture must be re-designed from scratch. The Separation of Duties principle and the Principle of Least Privilege must be strictly applied to the very last detail during design, and state-of-the-art technology must be used for implementation.

But we are so busy firefighting with new technology that we have no time to make strategies.

What might have stopped Snowden? I think a more fine-grained authorization concept, designed in strict application of the Separation of Duties principle, would have prevented the data theft.

Sounds easy, doesn’t it?

SearchSecurity.com: How to Thwart Privilege Creep with Access Reviews

5 July 2014

How to Thwart Privilege Creep with Access Reviews

In this E-Guide from SearchSecurity.com, industry expert Peter H. Gregory talks about privilege creep and the concepts to solve this problem.

The accumulation of privileges is bad enough but, things turn really bad if privilege creep undermines the Separation-of-Duties (SoD) or Four-Eyes principle. In this case employees could grant themselves unwanted privileges which could result in serious compliance problems.

When employees leave their job or retire we face a similar Problem. In the best case HR promptly notifies the IT group to deactivate the employee account. But privileges are very often excluded  for fall-back purposes because it takes a long time before a successor is fully able to work. In the worst case, if you are in a hurry, all those messy privileges are just copied without any review.

A regular review of privileges is the best measure to tackle these problems. Even manually reviews could be implemented with moderate effort. A IAM solution with direct link to the HR system is the definitely the best approach for a large company.

In addition, I recommend to expand job profiles by security profiles. When a new employee starts his work, the job related security profile could be easily implemented and thus privilege creep prevented.

Security profiles must be maintained to track changes in the job profile. A security profile comprises all roles and privileges to all applications, systems and information an employee needs to do his job.

In addition, the employee orientation plan must be expanded by information security related topics. Create awareness and train employees how to adequately respond to information security related incidents will raise the overall security Level.