Oracle has released the latest quarterly critical patch update (CPU). The database gets off lightly this time with two moderate severity vulnerabilities in SQL*Plus and the Oracle JVM. On the other hand, Oracle Secure Backup is not very secure with a bug that can be remotely exploited without authentication. Bad.
The Fusion Middleware stack gets 31 fixes, of which 20 are in the bad group of remotely exploitable without authentication. There is a lot of WebCenter stuff as well as some WebLogic and little Oracle Service Bus. Read the notes and update your environments.
Almost all of the Oracle applications (E-Business Suite, Siebel, J.D. Edwards) are also vulnerable, many through the critical Apache Struts 2 vulnerability (CVE-2017-5638). Oracle has fixed everything related to this Struts 2 bug in this CPU, but if you are running anything else based on Struts 2, make sure you update to a non-vulnerable version.
On a recent site visit, I went to the printer room to dispose securely of a draft of my confidential report. As expected, there was a container for confidential papers. As expected, it was locked. Unfortunately, the lock was only put through the bracket on the lid, not the container itself.
If I wanted to, I could have rummaged through all the departments’ confidential papers.
Much security is like this: Locked, but not secure. The organization suffers from all the impediments of spotwise strict security while overall security is still lacking.
The only way to build a secure IT infrastructure is to have someone regularly verify the security, including everything from the padlocks to the installation of vendor patches. This can be an internal compliance team or an external service – as long as the verification is not done by the people responsible for implementation.
IT suffers from Ostrich Syndrome: The belief that if you put your head in the sand and refuse to face facts, nothing bad will happen. Real ostriches don’t do this, of course – that would soon make them extinct. But IT does.
Finding the right amount to spend on all elements of IT (security, testing, fault tolerance etc) requires proper risk analysis. This is taught in Project Management 101, but recent events show that not everybody in IT understands this.
For example, the Democratic National Committee apparently thought that nobody would bother to attack their systems. After all, it just contained boring political emails, right? Wrong.
Similarly, Delta had apparently forgotten to attach about 300 computers to their uninterruptible power supplies, making their system very interruptible indeed. The had to cancel more than 2,000 flights.
Last month, it was Southwest Airlines who cancelled 2,000 flights, supposedly because a router went down. Talk about single point of failure…
Network segmentation, security patching, high availability, and disaster recovery all costs money. But being hacked or down also costs money. Did DNC, Delta and Southwest make the right call? I don’t think so. Maybe it’s time you looked at your risk analysis. Because you do have one, don’t you?
Oracle has released the July 2016 Critical Patch Upgrade, and there is some scary stuff there. Oracle has moved to the new CVSS 3.0 rating, which is the only reason they don’t score any perfect 10s (absolute worst). But there is still 19 occurrences of the scary 9.8 score: Remotely exploitable without authentication and with low attack complexity.
Among the products with these critical bugs:
- Oracle Retail
- Oracle Health Sciences
Maybe I shouldn’t have written about flexible security, because I immediately starting hitting inflexible security, locking me out.
Today’s fail is courtesy of MailChimp.com, which I use for my newsletters. It’s OK that they decided they want a confirmation when I log on to my account from India, but it is not OK that they require a text message passcode with no other option.
I have my phone in flight mode, because I don’t want to pay extortionate India roaming charges. But the Millennials in Atlanta running MailChimp have decided that everybody always have their phone on. We don’t, and they don’t know their users.
Do you know your users? Are you offering appropriate security options?
My customer just had to wait four hours for me to help them with an urgent issue, because they had not implemented flexible security as I wrote about recently.
Like many others, they are using two-factor authentication, which is good. Unfortunately, like many others, they depend on a text message as the second factor. Text messages are known to be unreliable and liable to be lost or delayed, but their IT department did not offer any flexibility: Without your passcode, you are locked out.
I did eventually get eight expired passcodes in a row. Fortunately, I did not have to revive a dead production database, and they survived the delay. But if you are depending on text messages to allow your system administrators to access your system remotely, do think about whether you need some alternative security option.
The apartment where I stayed in Venice has an impressive lock on the front door with four large steel pins going into the door frame.
The most interesting detail of this lock, however, is that you can decide how much security you want. If you just close the door, the latch will catch and the door cannot be opened without the key. If you turn the key once, the pins will extend a little bit into the frame, adding security. If you give the key another twist, the pins extend further, until the maximum security setting of four key turns. You can trade convenience for security, depending on how you perceive the threat of burglary while you are gone.
Most organizations have only one security setting in their IT systems. They implement a firewall to protect from outside threats and leave it at that. However, many threats come from inside. Analysis of the most serious security breaches in the last two years show that most are initiated by hackers using social engineering to convince insiders to break good security practice.
True security comes from a layered and flexible defense, not just one piece of networking kit. Can you give the key an extra turn in your organization?
Another week, another Java-related Security Alert. Oracle is calling this one CVE-2016-0636, and it comes with a CVSS risk score of 9.3, which means bad. Just visiting a malicious web site can give an attacker control of your machine.
Since Oracle Forms depends on Java, this means that all your client machines need this patch. If you are running an unsupported version of Oracle Forms, you have an unpleasant choice:
- Either you dare to let your clients run auto update, risking that one morning your Forms application is dead
- Or you don’t apply security patches automatically (or at all), leaving you open to attack
Fortunately, there is an easy solution: Upgrade.
I’m talking more about the future of Forms in this week’s Oracle Tool Watch newsletter.
The Ashley Madison security breach has again turned IT security (and the lack thereof) into front page news. Nobody in IT should be surprised that hacker attacks like this one is possible – after all, the Ashley Madison CTO managed to easily hack into a competitor’s website.
The problem all unsecure sites share is the all-powerful DBA, and that role needs to be reconsidered. You can take two different approaches:
- Trust but verify
Both of these approaches need to involve an IT security officer whose job is security and only that. The security officer should be a person not involved in database or system administration and should not share an office with the DBAs. The security officer belongs in your compliance organization and is more akin to an auditor.
If your data is truly sensitive, you should decide to enforce security (and accept a cost in lost productivity). With this approach, you place hard restrictions on what users can do. This includes securing that the DBA can’t read sensitive data and can’t grant access. Only the security officer can grant access and you ensure that nobody has both DBA and security officer roles.
If you focus more on productivity than absolute security, you can decide to trust but verify. You don’t place hard restrictions on your data, but monitor who accesses data. In this approach, the DBA can still read data, but not change the logging level or delete logs, and the security officer read these logs.
The problem is that most organizations follow a trust paradigm without the verify, and that is the way to Edward Snowden, the U.S.Office of Personnel Management and Ashley Madison. If you want to be secure, the all-powerful DBA has to go.
There are two approaches to security:
- Trust, but verify
The first places hard restrictions on what users can do. Advising development teams, I very often find that development workstations are locked down so tight that a developer can’t install a needed utility without logging a service request. The enforcement strategy always comes with a cost in lost productivity, but nobody bothers to count this cost.
The second places few restrictions on what users can do, but has a rock-solid audit function and people to actually monitor this. This approach doesn’t suffer the loss of productivity that enforcement does, but it does require you to generally trust your users to do the right thing. The problem with the trust & verify strategy occurs when organizations do not truly monitor what users do. This can allow malfeasance to go on for too long.
Make a decision which way you want to go. If you go with enforcement, make sure to calculate the cost. If you go with trust & verify, make sure you truly implement the “verify” part.