Tag Archives: Principle of least privilege

New York’s Cybersecurity Requirements for Financial Service Companies are a real game changer

1 November 2016

In post ‘Learn How the NYDFS Cybersecurity Regulations Will Impact Your Company‘ Shawn E. Tuma talks about the impact of the New York Department of Financial Services Cyber Security Regulation on the daily business.

Negotiating service contracts and working with third parties will require considerably more effort after the entry into force of the regulation. But a regulation has long been overdue, at least since the details of the Target data breach in December 2013 come to be known.

From a security point of view the Cybersecurity Regulation is a real game-changer. Some concepts are borrowed from the ISO 27001, but in some areas the NYDFS Cybersecurity Regulation goes much further than the ISO requirements.

The scope of the regulation, Nonpublic Information, is clearly and sufficiently broad defined in section Definitions (500.01). In my opinion, the focus on Nonpublic Information might create blind spots because significant damage can be caused by compromised Public Information as well.

Section 500.02 demands the implementation of a Cybersecurity Program. The program shall be designed to

(3) detect Cybersecurity Events;

(4) respond to identified or detected Cybersecurity Events to mitigate any negative effects;

The requirement ‘to mitigate any negative effects‘ is new, and will have a major impact on IT security operations.

Section Audit Trail (500.06) requires the implementation of a Privileged Account Management (PAM) solution.

Section Multi-Factor-Authentication (500.12) states, where Multi-Factor Authentication (MFA) is required. Unfortunately, MFA is not mandatory for the access to non-web applications. I would prefer so secure all applications with MFA.

The strict application of the Principle of Least Privilege, which is demanded in section Access Privileges (500.07), for access to Nonpublic Information is a big step forward.

All in all, the Cybersecurity Requirements for Financial Service Companies are a big step forward towards increased cyber security. If implemented well, the likelihood of data breaches will decrease dramatically.

If your company is implementing a cyber security program currently, it makes definitely sense to take a closer look at this regulation. It can be easily adapted to whatever type of business.

Have a good day.

Technical Account = Privileged Account = Member of the Administrators Group – It’s time to break this vicious circle

16 January 2015

I had some discussions in the past weeks about technical accounts in the administrators group. To be honest, I am a strong supporter of the ZERO administrators doctrine: Under normal conditions the administrators group of a computer has no members. If required, an account is added to the group and removed directly after the job is done. Strict implementation of a ZERO admin doctrine requires the implementation of a smart PAM solution to avoid undue delays in the case of trouble.

What really worries me is that technical accounts are always seen as privileged accounts. And that they are very often assigned to the administrators group for convenience, even though a system login is not required.

For example a technical account for querying a database needs no system privileges at all. Even a login to the application or database server is very often not required. In the best case the technical account only needs the privilege to open a database connection and to get access to a well-known set of database objects. Granting whatever system privileges to such accounts or assigning them to the administrators group enlarges only the attack surface of the system.

As always, the Principle of Least Privilege shows the direction. Grant privileges only if required, carefully evaluate if membership in the administrators group is necessary, and treat membership in the administrators group as an exception. To keep the attack surface small it’s wise to check the administrative groups for unnecessary technical accounts regularly.

Have a good weekend.

Ten years old but still up-to-date: Ten Tips for Designing, Building, and Deploying More Secure Web Applications

9 November 2015

Although the “Ten Tips for Designing, Building, and Deploying More Secure Web Applications” were published on 7 September 2005 the list still up-to-date.

I am discussing in particular tip 2 “Services Should Have Neither System nor Administrator Access” for years with internal developers and software vendors.

We have this under control in the case of in-house developed products, but many software vendors are still not ready to meet minimum security requirements. Very often neither the account name nor the password of service accounts can be changed, and this holds even on newly developed products.

This makes a regular password change for service accounts impossible. And extra effort is required to secure such systems once the account information is compromised.

Hopefully your systems meet the requirements and, the mentioned software versions are no longer in use.

Have a good week.

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.

The technology dimension of social engineering

7 February 2015

In his post ‘Weird Security Term of the Week: “Social Engineering”’ Kurt Ellzey talks of ‘Social Engineering’ as the ‘Art of Getting Information’ about a person.

A short query on Google reveals a multitude of information that could be used to create a rough profile of a person. A malicious insider could easily enhance this profile by personal information gathered from e.g. a company intranet or SharePoint MySites.

Besides this ‘personal information’ a rich set of easy to extract ‘technical information’ about an employee is available from a company network.

A Windows workstation is a universal machine. It can be used to run an application as well as to administer a server or network. For example, the built-in ‘net’ command could be used to retrieve detailed employee account data from the Active Directory.

Some colors to fight the winter depression.

Some colors to fight the winter depression.
50°53’28.3″N 4°21’31.9″E

IAM (Identity and Access Management) systems, very often deployed as self-services to improve user satisfaction, could be used to get detailed information about the applications used by employees to get their job done.

But the worst is that this information sources are available for all employees, irrespective of whether they are needed in the job. This is a massive violation of the Principle of Least Privilege.

Attackers can read in company networks like in an open book.

And, when enriched with technical information, a personal profile becomes an invaluable information source for targeted attacks.

Just some suggestions on how to tackle these problems.

As general design principle I would strongly recommend to enforce the principle of least privilege for all information systems. Software restriction policies could be used to reject standard user access to administrative commands. IAM systems should offer only user related information on a user’s request.

I dream of an operating system which provides only those commands and applications which are essential for a user’s job. This could reduce the attack surface of a company dramatically.

Have a nice weekend!

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.

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.

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?