Stop viewing IBM i as an impenetrable fortress. It’s not.
In one week, I’ll be speaking at the 2017 COMMON Annual Meeting and Expo, where I’ll be presenting a session called "IBM i and our False Sense of Security." I’ve done this session a couple of times now, and what I really try to go for is to strike sheer terror into the hearts and minds of audience members.
That’s right. Sheer terror in the form of a reality check that their systems are likely not as secure as they believe.
I want them to know—not think, but know—that there are many systems in the wild that are wide open. I want to talk about the worst of the worst examples. IBM i partitions with enabled QSECOFR accounts with QSECOFR as the password. Unencrypted FTP and HTTP connections that interface with customers, whilst accepting transactions, user IDs, and passwords all in plain text. There are businesses in the wild that are absolutely in serious risk of having their primary business machines taken offline or tampered with, or having their data stolen right from underneath their noses.
The goal is not to point fingers at others and think, “Well, at least we’re not that bad.” The goal is to make people view IBM i as a server that isn’t infallible. Specifically, their server. What makes IBM i fallible? It’s not the architecture. It’s the human element. It’s the person who set up a system 20 years ago and left Create Authority (QCRTAUT) at *CHANGE. It’s the person who creates a new user profile based on one with All Object authority. It’s the CFO who doesn’t view security as a concern and won’t listen to the IT manager’s plea for a professional IBM i security audit.
I’m not talking about fear, uncertainty, and doubt (FUD) either. It’s not paranoia if they’re really out to get you. And they are. And they will.
It’s easy to pass off security concerns with a shrug and think that it won’t happen to you. But it will. It probably has to some degree. Chances are many of us have no idea about it. If someone has stolen data, they don’t wave it around. They don’t make a copy and then delete it off the server it was stolen from. They take it and glean as much value from it as they can for as long as they can. The last thing a data thief wants to do is let on that they have your data. Once the alarm has been tripped, the value decreases on the goods. An example? Credit card numbers stored in plain text. It’s only a matter of time before all cards are cancelled. The value of those numbers drops with every passing hour.
So let’s talk about value. Cybercrime costs the global economy approximately $445 billion per year. Damage due to theft of intellectual property from hacking makes up $160 billion of that, or about 36 percent. Stolen credit card information costs the global economy about $200 billion, or 45 percent. Some estimates say that it’s not unreasonable to believe that we will spend up to a trillion dollars a year from 2017 to 2021 due to cybercrime.
It’s not hard to see why.
The BlackEnergy attack on a Ukrainian power grid back in December of 2015 that put 80,000 people in the dark for up to six hours was a stark reminder of how simple it is to bank on the reliability of the average email user to run a malicious macro in Excel. How much do you think that cost the Ukrainian economy? Six hours at the worst isn’t too bad. But the attack left 16 substation devices affected by firmware overwrites, leaving them unresponsive to remote commands from operators. This means workers had to control the power breakers manually. Now imagine if that happened in a large city like New York, Tokyo, or Seoul. Turning off the power in Cincinnati for three days would be bad. Disabling or altering control systems for any nuclear power plant in the world could have drastic consequences.
The nature of the Ukrainian attack is very similar to what happened in the unnamed water utility whose SCADA system (powered by an AS/400) was compromised by unprotected AS/400 credentials stored on a web server. In the Ukraine, SCADA networks were also compromised by way of harvesting user credentials.
The important commonality here isn’t SCADA but unprotected user credentials. You see, credentials don’t care about what kind of system you’re logging into. It doesn’t matter if it’s a Windows, Linux, IBM i, or mainframe operating system. Once someone is logged in with a user profile that has any kind of elevated authority, it’s game over. You’re at the mercy of the intentions of the intruder.
This is why we have to stop viewing IBM i as an impenetrable fortress. It’s not. IBM i is a great operating system that has the capability to be incredibly secure, but the average IBM i partition is not. If you think otherwise, check the PowerTech surveys year after year. It’s the same thing. Too many users with All Object (*ALLOBJ), Job Control (*JOBCTL), Spool Control (*SPLCTL) authority. Too many systems with FTP and REXEC active all day long. These problems seem to be an issue year after year after year.
Taking from my own experience, there are far too many companies that do not use encryption on their IBM i. And if they do, they’re usually not running quality encryption. For instance, most of the ciphers on IBM i 7.1 are broken, and half on 7.2 are broken. Far too many systems operate with password lengths of less than six characters, let alone 10, which in my opinion is not secure. Ideally, a system should have the capability to use up to 128 characters for a password and it should be enforced as a minimum of 15. It may sound like overkill, but password length beats complexity. That’s why password phrases are so effective.
If you look at special authorities, uncontrolled adopted authority, or excessive public authority to objects, it’s no surprise that many IBM i partitions could very well be the Achilles heel in an organization. There’s a certain irony there. People run IBM i partly because of the security characteristics, yet I’m becoming more convinced that with a little know-how, the average system could be compromised very quickly. The need to pull the reins in and start working on system security must be a top priority for any shop running IBM i. A properly secured IBM i is just about bulletproof. Getting to that level takes time and expertise. This is time we don’t have, considering that the amount of cybercrime has been on the rise exponentially in recent years and the aforementioned forecast is very bleak.
“It won’t happen to us” only lasts until it does. Forewarned is forearmed.
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online