Mary Ann Davidson wrote a great piece on her security blog today, which basically talked about focusing on the important vulnerabilities, not necessarily the ones that get the most press. Added to that, the risk associated with a vulnerability may well be different for you compared to everyone else, depending on how your system is used. I agree with what she is saying, but I’m going to take a slightly different angle on the subject.
Over the years I’ve come across lots of different attitudes to database patching from management and DBAs. As more DBAs are now involved in looking after middle tier products like WebLogic, some of those attitudes to patching have moved into that world too. It seems to break down into three camps.
- We don’t need no stinkin’ patches. If this is the way you roll you are a dumb-ass!
- We only patch stuff that represents a vulnerability for us. This sounds kind-of sensible, but life can get very difficult trying to decide what constitutes a threat, especially when you have to consider all layers of the technology stack.
- We always apply all patches. This is logically simple, but you are going to apply a lot more patches, a lot more frequently, which is going to require a lot more testing.
Patching is not just about security.
- Support of some products is tied into the patch version. We see this with Oracle products all the time. There are some important deadlines coming up soon!
- The rest of the world is moving on around you. You might be happy with your unpatched product, but things might break because of external factors. If someone turns off SSLv3 on their application server, you aren’t doing HTTPS callouts from your database to it unless you patch up to 126.96.36.199 or later. Your applications will probably get browser compatibility issues on newer browsers and mobile devices unless you keep on top of patching your development frameworks.
- Patches like the database PSUs come with extra functionality, including backports of features from newer releases (redaction – 188.8.131.52). They can also bring with them features that make future upgrades easier (transport database – 184.108.40.206 onward).
Choosing not to patch is not really an option these days. Your company has to understand this and allocate the correct amount of resource to getting it done. That might mean more staff resources allocated to patching and subsequent testing (rather than doing “productive” work), outsource the work where you can or moving to cloud services where regular patching is part of the deal.
I wrote about the Code Based Access Control (CBAC) stuff in Oracle Database 12c a while back.
I’ve recently “completed the set” by looking at the INHERIT PRIVILEGES and BEQUEATH CURRENT_USER stuff for PL/SQL code and views respectively.
It’s pretty cool, but I’m not sure how much of it I will see in the wild as it will require developers to do a bit more thinking, rather than doing what they’ve always done…
With all the recent press about global brute force attacks on WordPress I decided to install the Better WP Security plugin last Sunday.
It includes loads of security features, including the big ones mentioned in the recent attacks:
- Changing the name of the “admin” user.
- Changing the ID of your renamed admin user.
- Changing the table prefix.
- Max login attempts lockdown.
Of the 5 blogs I manage, 4 worked straight off with this plugin. Unfortunately, one required a few attempts, so remember to take filesystem and database backups before you start or you may not end up in a happy place.
Over the week since activating the plugin I’ve been quite interested/scared by the results. I’ve been getting several emails a day telling me of user lockdowns due to attempted brute force attacks originating from USA, Russia and the Netherlands.
If you have a self-hosted WordPress installation, you really need to take some basic steps stop yourself becoming a victim. There are a number of security plugins available, which I’m sure work equally well, but I only have experience of this one.
I had to laugh when I read this story about Amazon Web Services. It’s posted with an attention grabbing title that implies this is an Amazon problem, but it is squarely down to user error/oversight.
Luckily I’ve not fallen into this trap yet, but I have done equally silly things in the past. That reminds me, I must go to a Pete Finnigan session next time we are at the same conference…
I’ve just bought something over the net using my Barclaycard. As usual, the checkout screen bounces me to a Barclaycard verification screen. As usual it asks me for several letters from my password. As usual my password doesn’t work. As usual I reset the password. Not as usual, the screen then asks me for the 9th letter of my password when I only set an 8 character password. Phone call later my password is reset again. I complete my order. I have to rest my password, but can’t use the one I set previously as it “has been used to recently”.
If I was a thief I really couldn’t be arsed to go through this when I could just mug a granny in the street. I see now how Barclaycard security works. It bores people out of commiting credit card fraud… Sigh…
I’m quite big on password complexity. I like to use mixed case, numbers and special characters in my passwords.
Since having the iPad (and now the Android phone) I find it a real bind typing in strong passwords. The mixed case isn’t so bad, but I do have more login mistakes with the virtual keyboard. What really bugs me is having to switch keyboards two or three times to get all the special characters and numbers in. Every time I have to type a password on a mobile device I feel a certain tension…
My recent experience has left me thinking how nice it would be to have a weak password, preferably lower case letters only. So my next thought was, do virtual keyboards promote weak passwords?
Of course, I don’t expect anyone to comment and admit they have switched back to weak passwords, but it would be nice to know if anyone else feels my pain…
I’ve just posted an article on SecureFiles in Oracle 11g. It looks like Oracle have done a pretty good job of improving LOBs in 11g. Depending on the LOB contents, and provided you can cope with the processing overhead, you can certainly save some serious space using the compression and deduplication options. Anyone who’s used Transparent Data Encryption (TDE) will recognize the encryption options.
I can’t see the old-style (BasicFile) LOBs lasting very long now this is in place.
There’s some good stuff out on the net today:
- Tom is back and talking about the level of skills in the IT industry. I think we all share his pain.
- Mary Ann Davidson has a great piece on security. This links in nicely with what Tom was saying, in so far as it relates to skills with the IT industry, albeit from a security standpoint.
- Continuing the security theme, Pete Finnigan made some comments on my recent article on fine grained network access controls. I still get a kick out of being mentioned by famous bloggers, even if it is an attempt to keep me on the straight and narrow. Thanks for the heads-up Pete.
- Jake from Oracle AppsLab has a piece on the move back to the desktop. I find myself having conversations on this subject so often these days.
- Finally, David Aldridge is trying to add fuel to a fire.
Sorry to everyone I didn’t mention.
Continuing my OCP 11g upgrade campaign, I’ve been looking at Fine-Grained Access to Network Services in Oracle Database 11g Release 1.
This represents a pretty major security improvement for Oracle 11g. In previous versions the all-or-nothing security associated with database callouts was a little ham-fisted to say the least.
On the down side, I think it will confuse a few people when they are upgrading existing databases, but it’s a small price to pay for the peace of mind.
Someone on my forum was having a problem with the Secure External Password Store feature and to be honest I hadn’t got a clue because I had never used this feature. A few minutes of messing about with it resulted in this: