You need to regularly be reviewing news sources for announcements about cybersecurity threats, vulnerabilities, and exploits if you are working anywhere in the IT field. There have never been more threats to our digital footprints than there are right now, and attackers are getting more ingenious with their attacks every day.
I used to not care about following this type of news, but then the recent SharePoint legacy server exploit hit close to home for my team. We weren’t negatively impacted, but we could have been. Thankfully, other people at my company were already keeping on top of those things so we were able to act immediately to secure our server as soon as the vulnerability was announced.
My team is also diving heavily into the AI space, which has been riddled with vulnerabilities and hacks this year, which I’m also now able to keep on top of by following a few websites.
To make it easier to see recent news at a glance, I decided to make myself an RSS feed (is that outdated?) to follow a handful of the top cybersecurity news sites so that I could quickly get an overview of what’s being discussed.
Sites I am following
In my RSS feed for cybersecurity news, I am following these websites:
Dark Reading
The Hacker News
SecurityWeek
Ars Technica Security
The first two on the list, Dark Reading and The Hacker News, are the ones I end up clicking through to the most, but all have good feeds that you can follow easily. I personally am using feedly.com as my RSS reader tool, but you can follow the sites however you choose. Just make sure you read regularly since new threats are coming out all the time.
As technical professionals, those of us in the IT field tend to lean towards writing with technical language when we are communicating with others, whether that is with other members of our own teams or with business users or customers. While we may find our technical writing easy to understand, that may not be the case for others that we are working with.
Recently I was writing an email to a business customer in another part of my company who we made a custom chat bot for, trying to explain to her how the bot was able to give great answers even if the information it was providing was not explicitly written within the documentation we had given the bot for the Retrieval-Augmented Generation (RAG) model. Writing that email turned into a 20 minute learning experience of how I could simplify my explanation to a level that a normal business user would understand. I’m not sure why this idea popped into my head today, but I remembered that there are online services that will check the reading level of your writing, so I put my email draft into one of those and was surprised by the outcome and knew I needed to rewrite the email to be easier to understand for non-technical people.
Based on different studies and models, it is estimated that the average reading level for an adult in the United States is around the 7th-8th grade level[1]. There are other estimates that say that 54% of adults in the U.S. have a 6th grade reading level or below[2], which is a startling statistic.
I bring those statistics into this post because they point out why we as technical professionals may need to change our writing behaviors, especially when communicating with non-technical business users or customers. We need to make sure others understand what we are trying to say. If we are writing at a college level but the average person can only comprehend up to a 7th or 8th grade level, there are going to be misunderstandings.
Check Reading Level Online
In the email I was writing about how our chat bot worked, when I realized that it was overly complicated from a business user’s perspective, I started researching concrete changes I could make to how I wrote the message to make it more understandable to a normal, non-technical person. I love being in the weeds of the technicalities, but I know most of our business customers don’t; they only want to know how to use the tool to help themselves.
The best resources I found were the “Hemingway Editor Readability Checker” and then an older PDF document from Montclair State University which walks through getting analysis of writing in Microsoft Word. Jump to the section below to learn more about the Microsoft Word method.
The “Hemingway Editor” is a simple website where you can paste in your text you’d like to check, or provide a full text document, and it will do a quick analysis and highlight sentences that are hard to read, very hard to read, or not hard to read at all. It also gives a numeric “Grade” value indicating at what grade someone would be able to read the text.
When I pasted in my original email draft, it rated it at Grade 14, and marked all sentences in the text as either hard to read or really hard to read.
That review confirmed that I needed to rewrite the email to be less technical and easier to understand for average people. The website recommends aiming for Grade 9, which is what I tried to do. After a lot of editing, I got the score down to 10, which was as close as I could get to 9 without completely changing what I was trying to communicate.
Check Reading Level with Microsoft Word
If you don’t want to use the online editor to check your writing level, there is also the option to do that through Microsoft Word. Before you can check the reading level, you first must enable an option to do that.
In Word, go to File > “Options”, then “Proofing”. Under that page, check the box for “Show readability statistics”. Click OK to save the change.
Once you have enabled the feature, you can then go to the “Review” tab and click the button for “Spelling and Grammar”.
When you click that, you will first get a panel that will point out any grammar issues that the program has found. If you don’t care about that, you can click the “X” at the top left of the window (next to “1 remaining”) to close those suggestions.
After closing the grammar window, you will then get scores for your writing and recommendations for fixing the writing. There is also an option to check the similarity of the text to what can be found online, which might be useful for teachers and professors that are reviewing the writing of others and who may be concerned about plagiarism.
If you keep scrolling almost to the bottom of that recommendations panel, you can click on the “Document stats” button under the “Insights” heading, which will bring up a separate window with the reading level information and other details about your writing.
While there are other statistics about my writing that could be helpful in other scenarios, what I am most interested for this example is the “Flesh-Kincaid Grade Level”. In this case, Microsoft Word recognizes the same reading level as what the online checker has for my simplified email. Which is cool.
Reading Level for this Post
I got curious while writing this post, wondering what its reading level would be. The answer? 12.2 according to Microsoft Word and 13 according to the online Hemingway Editor.
I thought it would be higher, so I’m glad to see that it hopefully isn’t unreadable for your average IT professional.
Summary
Technical people are often bad communicators, especially when it comes to interacting with non-technical people. I can’t say that we’re all terrible at it, but many technical degrees require technical communication classes for a reason. I am as guilty of too-elaborate writing as others are. But I am now going to intentionally work on better summarizing myself when emailing and talking with my business users. I would never want to make someone feel dumb because I was talking at too high a level.
Do you have an old or bad Oracle admin password that you’ve been putting off changing because you’re scared of the impacts? Has your Oracle SYS user password been through the hands of multiple generations of database developers? Or maybe you just need to start regularly rotating your admin passwords to meet auditing guidelines? If you answered yes to any of those, I am here to help you make the change of your admin passwords on your Oracle Cloud Infrastructure (OCI) databases.
This post focuses on changing the passwords for OCI databases and pluggable databases. I specifically have done this on database version 23.9.0.25.07 and 19.0.0.0. The process was exactly the same for both, and is covered fully in this post.
As we all know, password security is one of the easiest ways to increase the security of any account you own, which will include the admin accounts for your OCI database. There have been countless data breaches across all sectors, even ones you would think would be better at making strong passwords, due to people using too simple of passwords like “admin123” or “password”. We want to be better than that.
Regular rotation of your strong passwords will also increase the security posture of your system, which is another reason you may want to consider changing the passwords of your SYS and SYSTEM users on your database, especially when I show you how easy it is to do.
Disclaimer: This process worked for me and my systems using the OCI databases, it may not work as flawlessly for you. If your overall architecture includes having applications use these admin accounts for access, changing the password could break those systems. Make sure you don’t have any applications, pipelines, or processes using these accounts before you start. Or simply be aware that they will all have to be updated with the new password once you change it on the database (but don’t be that person, use service accounts or managed identities instead!).
Change the SYS User and TDE Wallet Passwords through the Console
The best and easiest way to change the password for your SYS admin account on an OCI database is to do so through the OCI console. If you navigate to the database you need to make the change for (not the Database System or the Pluggable Databases, just the Database level), you can find the option to change the passwords under the additional menu on the top right of the screen. Choose “Manage Passwords”.
That will bring open a pane that looks like this, which will allow you to change the password for your Admin account (SYS user) or for the TDE wallet.
You will only be able to change one of those passwords at a time. To change the admin user password, leave the option for “Update administrator password” selected, then enter the new password into both boxes. When you start typing, you will be provided the requirements for the password.
If you enter a password that doesn’t meet those requirements then try to save, you will get this error:
For my database, the password requirements are the following:
Length: 9-30 characters
Alphabetic characters:
Minimum 2 uppercase
Minimum 2 lowercase
Numeric: Minimum 2
Special characters:
Minimum 2
Only options are hyphen, underscore, pound
Once you click “Apply” to save the password, it will take about 2 minutes for the database to make the change. During that time, the state of the database will show as “Updating”.
If you would like to update the TDE Wallet password as well, you will need to wait for the other password change to apply first. It is just as simple to update that password as it was to update the admin password, except this time you must first specify the previous password along with the new password and confirmation.
Once again, the database will go into an “Updating” state once you click “Apply” to change the password. For me though, the TDE Wallet password took much less time to apply.
Change the SYS Password on the Pluggable Database Level
In my situation, once I updated the SYS password on the container database (CDB) level, the same change was automatically applied to all the Pluggable Databases (PDBs) within that CDB. Which was a surprise to me, since everything I was reading online before making the change seemed to indicate that I would need to make the change there as well.
I was able to confirm that the PDB SYS user password had been updated on all PDBs by updating my connections to them in my IDE to use the new password. Once that connection worked, I knew that the password had been updated everywhere.
Change the SYSTEM User Password on the Container Database
The console method of updating the main admin password for an OCI database unfortunately won’t update the passwords for all system users at the same time. In my case, I also needed to update the password of the SYSTEM user. (Curious how many system users there might be on your database? You can view the complete list here.)
To change the password of the user “SYSTEM” on an OCI database, you will need to connect to the container database (CDB) and run the ALTER USER command to change the password. You can do that through the terminal/command line or through an IDE. I chose to make the change through an IDE.
Since I wasn’t sure what was going to be required for updating this user, I decided to start at the Pluggable Database Level, where I ran this command: ALTER USER SYSTEM IDENTIFIED BY "password";. I got an error when trying to run that though:
I researched that error and found this Oracle help document, which indicated that changing the password for “common users” needs to be done at the CDB level, or the root level of the container database. Based on that, I then ran that same ALTER USER command on the CDB level and it completed without any issues.
I’m not sure why, but the SYSTEM user then became locked (or it was locked before I changed the password but I hadn’t seen that). After changing the password for that account, I wasn’t able to login on either the CDB or any of the PDBs with that user, so I was worried something had broken. However, logging in with a different user I was able to see that the SYSTEM user was locked on the CDB level, but not the PDB level, so I unlocked the account and was then able to login on the CDB and PDB level. And that also taught me that if a user is locked out on the CDB level that they will also not be able to login to any of the PDBs. Which makes sense for security purposes.
Change the SYSTEM Password on the Pluggable Database Level
As with the SYS user, once the SYSTEM user password was changed on the container database (CDB) level, the password for the account was also automatically changed on the pluggable database (PDB) level without me having to do anything.
Summary
The process of changing the admin account passwords on an OCI database is simple and straightforward if you know what you need to do. To change the SYS user password, use the OCI console on the container database level. To change the SYSTEM user password, as well as any other system/common user passwords, you will need to run an ALTER USER SQL command to make the change at the container database level. While I didn’t need to update the password on the pluggable database level at all, you will need to verify the same for your own system.
Have you ever tried to take a backup of your Azure Storage Account? If you did, were you able to actually set up and take backups for your Storage Accounts? I was not lucky enough to set up backups for a Storage Account recently when asked to by Microsoft Support, but I learned a lot in the process. Mainly that you cannot set up backups, either type, for Storage Accounts that have a hierarchical namespace enabled. Most of the Storage Accounts my team uses have that hierarchical namespace enabled, so we aren’t able to take advantage of the Azure backups for the Storage Account, which I find unfortunate. Hopefully this is a gap that will be filled by Microsoft sooner rather than later since it would be nice to have that extra level of data security.
As with many posts I write, this one is inspired by a recent problem I was dealing with at work, where it looked like something weird was happening with a Storage Account (spoiler: it wasn’t, see my previous post for more details). While working with Microsoft Support, they requested that I take a backup of the Storage Account where our Data Lake resides, then delete the seemingly problematic directory and recreate it from the backup. I never tried something like that, so I was ready to learn how to set up and take backups for Storage Accounts.
I went through all the necessary steps that should have led to making a backup, like setting up a backup vault and creating a policy. But when I got to the step where I need to add the Storage Account in question to the policy, I wasn’t seeing the Storage Account I wanted in the list of items available to backup. When I searched for something that should bring up a handful of accounts, only one item was listed, and it wasn’t what I needed to backup, which was confusing to me. I had to dig more to figure out why I couldn’t add my Storage Account to the backup policy.
What is a Hierarchical Namespace and Why Use It?
The Hierarchical Namespace is a checkbox that you can enable when creating an Azure Storage Account that gives you a true directory system for storing you files, much like File Explorer on your local machine. Without this setting enabled, you may see things that look like folders because there are slashes in the name of the objects, but those will be stored in a flat structure on the account. To improve data retrieval performance, you can enable the Hierarchical Namespace to create true directory structures so that you can work on whole directories at once instead of doing things one-by-one on blobs.
Storage Account Backup Limitations
When I didn’t see my Storage Account in the list of options I could add to my backup policy, I knew something was up. The main documentation from Microsoft that covers how to set up Storage Account backups does not mention at all that there are scenarios where the backups wouldn’t be possible. To find that information, you have to find a separate document which is called the “support matrix” for those backups.
On that page, if you look at the “Vaulted Backup” option, which is what I had set up after following the backup documentation, you will see that “HNS-enabled Storage Accounts are currently not supported. This includes ADLS Gen 2 accounts, accounts using NFS 3.0, and SFTP protocols for blobs.” If you didn’t now better, you might not even know that “HNS-enabled” means Hierarchical Namespace Enabled.
Tip! When writing documentation, always define your acronyms before using them. For more on writing to be easily understood, check out my other post here.
On that same support matrix page, if you flip over to the “Operational Backup”, which is the second method of enabling backups on Storage Accounts, you will see that those also don’t support backups for Hierarchical Namespace enabled accounts. At least this note doesn’t use an undefined acronym: “Storage accounts with hierarchical namespace enabled […] aren’t supported.”
Ramifications of Backups Not Working for Hierarchical Namespace Storage Accounts
I believe that this lack of backups for this type of Storage Account is a giant flaw created by Microsoft. They are pushing the use of Storage Accounts as Data Lakes, hence the “Azure Data Lake Storage Gen 2” (ADLS Gen 2) Storage Account settings being heavily marketed. Data Lakes are meant to be a modern way to handle data, yet we are not afforded modern solutions for backing up that data. (Maybe it’s because they’re trying to move everyone to OneLake on Fabric so don’t care about Storage Account data lakes anymore…)
You could argue that Data Lakes should never be a source of data and should be reproducible in the event of a disaster from the true data sources, but I believe that is a backwards mentality for managing any data in 2025. Sure, our data in our Data Lakes could be remade by running pipelines, but then we would lose the change history of the data that resides across the versioned Parquet files in the Storage Account, which is sometimes very helpful for troubleshooting.
With no standard backup solution for Storage Accounts with Hierarchical Namespace enabled, that means customers utilizing the accounts for Data Lakes are left vulnerable to data loss, even if they have geo-redundancy. Cross-region redundancy does not guarantee that the secondary location has the exact same data as the primary at the moment of failover.
My advice for people using hierarchical namespaces on their Storage Accounts is to create your own backup solution if losing those files would critically affect your business if lost. Write the files to two Storage Accounts at once, or something along those lines. I am a naturally cautious person that likes to have backups for backups, so I wouldn’t leave the security of critical files in Microsoft’s hands. In all likelihood, your files will probably be fine for 99.9999999% of the time, but that small chance of data loss may not be one you’re willing to take.
Summary
As of the writing of this post, Microsoft does not provide any method for creating backups of Storage Accounts using the Hierarchical Namespace settings to give directory organization to the account. If you are using this type of Storage Account and are storing business-critical files, create a secondary backup solution for yourself to ensure you won’t be susceptible to data loss you have no control over.
